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