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