Re: [boost] Boost.Fiber - interruptible fibers

Subject: Re: [boost] Boost.Fiber - interruptible fibers
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-01-11 16:12:47

Le 11/01/14 19:40, Nat Goodspeed a écrit :
> On Sat, Jan 11, 2014 at 12:50 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>
>> Boost.Thread interruption feature adds some overhead to all the
>> synchronization functions that are interruption_points.
>> It is too late for Boost.Thread, but what do you think about having a simple
>> fiber class and an interruptible::fiber class?
> That's particularly interesting in light of recent remarks about the
> cost of thread-safe fiber state management.
>
> Going out on a limb...
>
> Could we identify an underlying interruption-support operation and
> tease it out into a policy class? Maybe "policy" is the wrong word
> here: given the number of Fiber classes that would engage it, adding a
> template parameter to each of them -- and requiring them all to be
> identical for a given process -- feels like the wrong API. As with the
> scheduling algorithm, what about replacing a library-default object?
> Is the interruption-support overhead sufficiently large as to dwarf a
> pointer indirection that could bypass it?

The major cost is not on the fiber class but on the 
condition_variable::wait operation. Next follows the implementation 
found on CCIA

void interruptible_wait(std::condition_variable& cv,
                         std::unique_lock<std::mutex>& lk)

{
     interruption_point();
     this_thread_interrupt_flag.set_condition_variable(cv);
     cv.wait(lk);
     this_thread_interrupt_flag.clear_condition_variable();
     interruption_point();

}

If a template parameter should be used I will vote for a boolean. C++ 
Concurrency in Action Whether the class fiber is parameterized or we 
have two classes fiber and interruptible_fiber could be discussed.
> Similarly for fiber state management thread safety:
>
> Could we identify a small set of low-level internal synchronization
> operations and consolidate them into a policy class? Maybe in that
> case it actually could be a template parameter to either the scheduler
> or the fiber class itself. I'd still be interested in the possibility
> of a runtime decision; but given a policy template parameter, I assume
> it should be straightforward to provide a particular policy class that
> would delegate to runtime.
It is clear that a fiber that can communicate only with fibers on the 
same thread would avoid any thread synchronization problems and perform 
better. I'm sure that there are applications that fall into this more 
restrictive design.

Here again can have a template parameter to state if the fiber is 
intra-thread or inter-threads.
> Then again, too many parameters/options might make the library
> confusing to use. Just a thought.
>
Right. But for the time been we have just identified two parameters, 
which are not too much.

Vicente