Re: [boost] [thread] A few submissions

Subject: Re: [boost] [thread] A few submissions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-07-04 17:49:14

>>>> 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>

>>>> 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.

> 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.

>>> 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?

> once-blocks, no, but why not rw mutexes and shared_lock_guard?

rw mutex is process-local and I'd like to keep it that way. Regarding 
lock types, I have no strong opinion, but I have no problems with using 
locks from Boost.Thread on any type that models the appropriate concepts.

>> And I don't see the point of creating a new library for these
>> things. IMO, they fit just fine in Boost.Thread.
>
> There is no reason to have two unique_lock, ... If you had to use
> some generic synchronization mechanisms for process mutexes, will you
> look at the thread library?

It's a question of finding the information about the lock types. If 
Boost.Interprocess docs have a link to Boost.Thread locks, then yes, I 
would find it.