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

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-01-09 17:49:23

Le 09/01/14 23:29, Oliver Kowalke a écrit :
> 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
You are surely right, but I don't see how? Could you show it?
>
> 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)
Could you post here an example at the user level?
>
>
>> 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
Why do the user needs to own the scheduler?
>
>
>>     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)
I give you un example using system_clock. The opposite is of course possible
> - member-functions of sync classes like condition_variable::wait_for()
> takes a time_duration or condition_variable::wait_until() a time_point
And? Take a look at the thread implementation of e.g. libc++ which is 
form me the best one.
> time_duration + time_point can be of arbitrary clock-type from boost.chrono?
No.
> can I simply add a time_duration different fro msteady_clock to
> steady_clock::now()?
There is no time_duration time. Just duration. duration can be added to 
any system_clock::time_point, steady_clock::time_point or whatever 
timepoint<Clock, Duration>.
>
>
>>
>>>   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?
>
>
>
The completion function can be used to reset the barrier to whatever new 
value you want, for example.

Vicente