Re: [boost] [thread] A few submissions

Subject: Re: [boost] [thread] A few submissions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-07-04 17:14:29

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, July 04, 2010 10:26 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?

>>> 2. Lightweight read/write mutex. Basically, I want a portable analogue
>>> for pthread_rwlock_t, with minimum dependencies, code size and memory
>>> footprint. Naturally, it is compatible with Boost.Thread locks.
>>>
>>> Why not shared_mutex:
>>> * shared_mutex.hpp depends on a lot of other headers. It brings in a
>>> great deal of Boost.DateTime, although I don't need the timed methods at
>>> all.
>>
>> I consider the timed functions a must to have.
> 
> 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.
 
>> What about making it depend on Boost.Chrono instead?
> 
> 1. It's not accepted.

I hope it will be soon.

> 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.
 
>>> * 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);

 
>> Is there any constraint to don't make your Lightweight read/write mutex upgradable?
> 
> On Windows NT6 SRWLOCK doesn't support upgrades. 

This should be a good reason to don't support upgrades :(

> And I don't know how to 
> upgrade pthread_rwlock_t.
> 
>>> 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? :(
 
>>> 5. The strictest_lock metafunction. Given the list of lock types, it
>>> selects the one that offers the strictest concurrency guarantees (i.e.
>>> shared lock is stricter than no lock at all, exclusive lock is stricter
>>> than shared lock). This metafunction can be useful in generic code,
>>> where the final lock type must be deduced.
>>
>> Could you show a usage example?
> 
>   typedef shared_lock< shared_mutex > lock1;
>   typedef unique_lock< shared_mutex > lock2;
>   typedef strictest_lock< lock1, lock2 >::type lock3;
>   BOOST_STATIC_ASSERT(is_same< lock2, lock3 >::value);

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 understand that some of these tools might seem specific to my case,
>>> but I think they could be useful in general. If any of these tools is
>>> accepted into Boost.Thread, the code is not set in stone - namings and
>>> implementation details can be changed, if needed. I can do the code
>>> transition, write docs and a few tests, if needed. Just let me know if
>>> either of these is of interest and whether I am allowed to do so.
>>
>> 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.
 
>> Most of the synchronization features should work as well for interprocess. What about including all the synchronization features in a separated Synchro library?
> 
> I don't think that things like once-blocks or rw mutex are relevant to 
> Boost.Interprocess. 

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

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

Best,
Vicente