Re: [boost] Boost.Fiber review January 6-15

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-09 17:29:23

2014/1/9 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>

> struct X {
>>    operator bool() {}
>> };
>>
>> struct Y {
>>    operator bool() {}
>> };
>>
>> X x; Y y;
>>
>> if ( x == y) // does compile
>>
>>  I don't see the problem with explicit conversion
>
>>
you can compare X and Y

Is there an example showing this on the repository?
>

no its is an implementation in side the framework, e.g. class scheduler
which holds the user-defined or the default
implementation of the scheduler-impl (default is round_robin)

> Can the scheduler be shared between threads?

no - not the schedulers (== classes derived from interface algorithm, e.g.
round_robin and round_robin_ws)
which might be share-able between threads but I doubt that it would make
sense - a scheduler derived from alogrithm
schedules the fibers running in the current thread

>    Maybe schedulers need to take care of a single time_point, but the other
>>
>>> classes should provide an time related interface using any clock.
>>>
>>
>> OK - boost.chrono is your domain. functions accepting a
>> time_duration/time_point (from boost.chrono) can always be mapped/applied
>> to steady_clock/system_clock?
>>
> No mapping can be done between clocks and there is no need to do this
> mapping. This is how standard chrono libray was designed. Please take a
> look at the following implementation
>
>         template <class Clock, class Duration>
>         bool try_lock_until(const chrono::time_point<Clock, Duration>& t)
>         {
>           using namespace chrono;
>           system_clock::time_point     s_now = system_clock::now();
>           typename Clock::time_point  c_now = Clock::now();
>           return try_lock_until(s_now + ceil<nanoseconds>(t - c_now));
>         }
>         template <class Duration>
>         bool try_lock_until(const chrono::time_point<chrono::system_clock,
> Duration>& t)
>         {
>           using namespace chrono;
>           typedef time_point<system_clock, nanoseconds> nano_sys_tmpt;
>           return try_lock_until(nano_sys_tmpt(ceil<nanoseconds>(t.time_
> since_epoch())));
>         }
>
> Note that only the try_lock_until(const chrono::time_point<chrono::system_clock,
> nanoseconds>& ) function needs to be virtual.

seem to me at the first look that it woul be compilcate in teh case of
boost.fiber because:
- the scheduler (derived from algorithm, e.g. for instance round_robin)
uses internally a specific clock type (steady_clock)
- member-functions of sync classes like condition_variable::wait_for()
takes a time_duration or condition_variable::wait_until() a time_point

time_duration + time_point can be of arbitrary clock-type from boost.chrono?
can I simply add a time_duration different fro msteady_clock to
steady_clock::now()?

>
>
>>  I made some adaptations to boost::barrier that could also have a sens for
>>>
>>>> fibers.
>>>>
>>>>  OK - what are those adaptations?
>>>
>>>  See
>>
>>> http://www.boost.org/doc/libs/1_55_0/doc/html/thread/
>>> synchronization.html#thread.synchronization.barriers and
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/
>>> n3817.html#barrier_operations
>>>
>>
>> OK - that's new to me, but I don't know the use case of completion
>> function
>> etc. - do you have some hints?
>>
> From the pointed proposal
> "
>
>
>        A Note on Completion Functions and Templates
>
> The proposed barrier takes an optional completion function, which may
> either return void or size_t. A barrier may thus do one of three things
> after all threads have called |count_down_and_wait()|:
>
>  * Reset itself automatically (if given no completion function.)
>  * Invoke the completion function and then reset itself automatically
>    (if given a function returning void).
>  * Invoke the completion function and use the return value to reset
>    itself (if given a function returning size_t)."
>
> As you can see this parameter is most of the time related to how to reset
> the barrier counter.
>

ready this too but do you have an example code demonstrating a use case,
sorry I've no idea which use cases would require a completion function?