Re: [boost] Boost.Fiber - interruptible fibers

Le 11/01/14 19:40, Nat Goodspeed a écrit :

On Sat, Jan 11, 2014 at 12:50 PM, Vicente J. Botet Escriba 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_lockstd::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