Open DanielMehlber opened 9 months ago
From my experience with the library, it treats all stacks as fibers even the main one, so locking a fiber mutex from the main thread will just work.
The thread's primary stack will just be blocked for the time it can't get the mutex. If there are no other fibers on that thread, that thread will appear idle.
Hello dear developers,
This is more a quesion than a bug: When using fibers, the mutex provided by this library
fiber::mutex
is recommended because a normalstd::mutex
does not know about fibers and might cause deadlocks in certain scenarios. So far so good.I basically have a pool of worker threads executing fibers (like a task- or job-system where each job is a fiber) using the shared_work scheduler (just for context, not relevant). Due to shared-memory between jobs, these fibers often use mutexes and locks. So far, this is a clear scenario because the only ones trying to lock the
fiber::mutex
are fibers running on dedicated worker threads.However, the main thread (or any other normal thread) sometimes wants to access these shared resources as well. It also tries to aquire a lock on the
boost::fiber::mutex
without being a fiber. I first hoped that thefiber::mutex
class would work both with fibers and normal threads alike, but it does not, right?Instead, I assume that these mutexes highjack the main thread's context, for instance, and stash it away regardless of it not being a fiber. This suspends and main threads execution and often results in a deadlock-ish scenario where the program is stuck.
When looking at the mutex code, this behavior seems to be deliberate, not a bug.
Am I right in the assumption that
fiber::mutex
cannot be mixed with normal threads? If you had a scenario in which both normal threads and fibers would try to access the same shared memory, how would you protect/synchronize it?Thanks in advance!