A thread with TSO_LOCKED can be migrated if the number of capabilities decreases.
Ryan On Tue, Oct 27, 2015 at 11:35 PM, Edward Kmett <[email protected]> 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 > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
