Temporarily pinning a thread to a capability

[Simon Marlow]

If you don't mind threads moving around between calls to your 
primitives, this should be ok.

Cheers,
Simon

On 27/10/2015 23:35, Edward Kmett wrote:
> Would anything go wrong with a thread id if I pinned it to a capability
> after the fact?
>
> I could in theory do so just by setting
>
> tso->flags |= TSO_LOCKED
>
> and then disabling this later by restoring the TSO flags.
>
> I can't think of anything but I figured folks here might be able to
> think of invariants I don't know about.
>
> Usage scenario:
>
> I have a number of things where I can't afford a map from a ThreadId# or
> even its internal id to a per-thread value for bounded wait-free
> structures.
>
> On the other hand, I can afford one entry per capability and to make a
> handful of primitives that can't be preempted, letting me use normal
> writes, not even a CAS, to update the capability-local variable in a
> primitive (indexing into an array of size based on the number of
> capabilities). This lets me bound the amount of "helpers" to consider by
> the capability count rather than the potentially much larger and much
> more variable number of live threads.
>
> However, I may need to access this stuff in "pure" code that wasn't
> written with my needs in mind, so I need to at least temporarily pin the
> current thread to a fixed capability for the duration when that happens.
>
> This isn't perfect, it won't react to a growing number of capabilities
> nicely in the future, but it does handle a lot of things I can't do now
> at all without downgrading to lock-free and starving a lot of
> computations, so I'm hoping the answer is "it all works". =)
>
> -Edward