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]>
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
>> 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.
/* upgrade the 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
>> 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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk