On Thu, Jan 16, 2014 at 9:27 AM, Thomas Heller
Even in the context of a Boost.Fiber like library, you have to take extra care to secure your data structures from concurrent access. Even though it is not necessarily running any threads in parallel, a fiber can suspend while being in a critical section. BTW, from our experiences with HPX, such a behavior (suspending a user level thread while a lock is held) is very dangerous and often leads to deadlocks. That being said, even when you decide to use fiber with your legacy code, the cost to make it safe is not really negligible.
Your point is well-taken. Introducing a new fiber -- let's say "a cooperatively-concurrent thread" -- into code *partially* retrofitted for kernel threads is more dangerous than in code which has always before run on a single thread; in other words, code with no kernel-thread synchronization constructs. You can grep for kernel-thread synchronization constructs, though. Being certain that you have located and adequately defended every potential access to a process-global resource is significantly harder.