Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Nat Goodspeed (nat_at_[hidden])
Date: 2014-01-16 09:23:07

On Thu, Jan 16, 2014 at 9:27 AM, Thomas Heller <thom.heller_at_[hidden]> wrote:

> 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.