Race condition when migrating fibers to different threads

Ah... I've determined that it *doesn't* work on dmd/windows/tango 0.99.8. It still crashes, but it just silently brings down one thread, and the other thread just sits there waiting. Attaching patch to fix...

Doh... copy paste error. The explanation is that there is a race condition when Fiber.state == State.HOLD, but the Thread still has a reference to the Fiber's context. When you call Fiber.yield(), m_state is set to HOLD prior to switchOut(), and set to EXEC after switchOut returns (i.e. the fiber as been called again). However, the Thread holds a reference to the Fiber's context until we call popContext in switchIn (where we return to after calling switchOut). So, the solution is to not set the state inside the fiber itself, but set it to EXEC in switchIn prior to calling pushContext(), and after the Fiber has switched itself back out, set it to HOLD after calling popContext. This will guarantee that when m_state == HOLD, no Thread has a reference to the fiber. When m_state == EXEC, we're either really executing, or we're in the middle of manipulating Thread state to associate/disassociate the fiber with the thread.

Thanks I will look into it, thread switching is very "touchy", and I need to think it through calmly.

somewhat unrelated, with my scheduler I have recently found a bug i the gc, something that can lock at least on mac: suspendAll has a semaphore, and the call to it is not signal safe, and may (seldomly) lock when another thread is qcquiring a lock then suspended. I am not yet fully sure about how to fix it.

I would say that what you say looks reasonable, just a note: assuming that all assignements have been propagated when transferring a fiber, especially with Numa may not be fully justified...

Hmm... interesting. I need to do some more research, but I'm running into an issue with a piece of code that allocates thousands of tiny fibers unexpectedly crashing. The crash appears to be in munmap, so my suspicion is that the GC is garbage collecting the fiber object before it has fully finished executing. Do you think this could be related to what you found above with the semaphore?