Subject: Re: [boost] [thread] A few submissions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-07-04 16:26:39
>> 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:
>> void foo()
>> puts("Hello, world once!");
>> The code within the block can access names (e.g. variables) as if it was
>> a usual code block.
> I like this construction. What about renaming it BOOST_ONCE?
Like I said, I'm not tied with naming.
> 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.
>> 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.
> What about making it depend on Boost.Chrono instead?
1. It's not accepted.
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.
>> * It offers more than I ever use. I don't need upgradeability.
> pthread_rwlock_t are upgradable.
Is it? Through what functions?
> Is there any constraint to don't make your Lightweight read/write mutex upgradable?
On Windows NT6 SRWLOCK doesn't support upgrades. And I don't know how to
>> 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. :)
>> 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);
>> 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.
> 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. And I don't see the point of creating a new library
for these things. IMO, they fit just fine in Boost.Thread.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk