Re: [boost] [thread] A few submissions

Subject: Re: [boost] [thread] A few submissions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-07-04 18:13:06

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, July 04, 2010 11:49 PM
Subject: Re: [boost] [thread] A few submissions

> 
>>>>> 1. Once-blocks. This is a flavor of the "once" concept. One can
>>>>> define a block of code that should be executed only once, like
>>>>> that:
>>>>>
>>>
>>>> Could you explain how do you ensure that the code is thread
>>>> safe?
>>>
>>> I run the test multiple times on a multi-core machine. Never
>>> failed.
>>
>> Well, this should not be enough. Could you explain what have you do
>> protect from concurrent access?
> 
> The once flag is only modified when an internal mutex is locked. If a 
> thread entered the once-block, all other threads are blocked in a 
> condition variable. Take a look at the code for more details.
> 
>>> You can always use shared_mutex. I use timed functions quite
>>> rarely.
>>
>> Well, as you said shared_mutex is not as Lightweight as the user
>> expects.
> 
> That's right. You want more features - you pay with longer compile times.
> 
>>> 2. I don't think that switching Boost.DateTime to Boost.Chrono does
>>> much good in terms of lightness. Remember, one of my goals is to
>>> make it extremely cheap to include.
>>
>> Why is so important that is be extremely cheap to include? What is
>> important for me is run-time and storage used.
> 
> I also want to shorten compile times.
> 
>>>>> * It offers more than I ever use. I don't need upgradeability.
>>>>
>>>> pthread_rwlock_t are upgradable.
>>>
>>> Is it? Through what functions?
>>
>> If I remeber you just need to tale the mutex for write once it was
>> taken for read.
>>
>> pthread_rwlock_rdlock(mutex); /* upgrade the mutex*/
>>
>> pthread_rwlock_wrlock(mutex);
> 
> This us undefined behavior:
> 
> <http://opengroup.org/onlinepubs/007908775/xsh/pthread_rwlock_wrlock.html>

Oups. I missed a sentence.
 
>>>>> A few notes up-front. There are extensions in some compilers
>>>>> for TLS support. It offers even better performance and easier
>>>>> to use. Also, C++0x will bring this feature into the language.
>>>>> But: * It is known to have problems with dynamically-loaded
>>>>> modules. * It is not portable. Even when C++0x it out, not all
>>>>> compilers will support it right away. * thread_specific does
>>>>> not require the variable to have a static storage duration.
>>>>
>>>> Stefan Stasser has proposed a stati_thread_specific_ptr (see
>>>> attached file). What about a static_thread_specific that could be
>>>> implemented using the C++0x thread_local, when available?
>>>
>>> Please, see my up-front notes, I've already answered. :)
>>
>> Do you mean that at the end the  C++0x standard will have problems
>> with dynamically-loaded modules? :(
> 
> I mean that current compilers have this problem. Whether the 
> C++0x-conforming implementations will solve it or not is yet to be seen.

Then if I understand your thread_specific class doesn't have any issues with dynamically-loaded
modules, isn't it? If this is the case, could you clarify how your class avoids the problem?
 
>> Sorry, I was not enough clear. Could you show an example on which the
>> lock to be used is the strictest_lock of two locks, a use case if you
>> want?
> 
> I use it in logger features in Boost.Log. Say, we have N features that 
> derive from one another and implement an operation and require a certain 
> concurrency protection. Each feature can require a different protection.
> 
>   template< typename T >
>   struct feature1 : T
>   {
>     typedef typename strictest_lock<
>       typename T::op_lock,
>       shared_lock< ... >
>     >::type op_lock;
> 
>     void op(); // requires shared_lock and calls T::op
>   };
> 
>   template< typename T >
>   struct feature2 : T
>   {
>     typedef typename strictest_lock<
>       typename T::op_lock,
>       unique_lock< ... >
>     >::type op_lock;
> 
>     void op(); // requires unique_lock and calls T::op
>   };
> 
> Now, if we instantiate feature1< feature2< ... > >, the resulting 
> compound will have the op_lock type that satisfies all features.

OK, I see. This seems a valid use case.
 
>>>> I'm interesteed. Why don't request a mini-review of the proposed
>>>> features as a Boost.Thread extension?
>>>
>>> Well, I don't know how to do it formally. Consider this a request.
>>
>> I considere this a request for interest, not a request for a
>> mini-review.
> 
> What stops it from being a mini-review?

packaging, documentation, tests, ...
 
Thanks,
Vicente