Subject: Re: [boost] [thread] A few submissions
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-07-04 15:35:36
----- Original Message -----
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
Sent: Sunday, July 04, 2010 7:15 PM
Subject: [boost] [thread] A few submissions
> I would like to propose the following components for inclusion into
> 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?
> Why not call_once:
> * The once-code is defined in-place, which greatly simplifies usage in
> many cases. One of the main goals of the "once" concept is the dynamic
> initialization, which involves the variables being initialized. With
> once-blocks there is no need bind these variables into a functor.
> Once-blocks are also easier to be used within a macro.
> * The resulting code is much shorter since the thread synchronization
> code is separated from the once-code. call_once is instantiated with
> each once-functor, although the synchronization code is the same.
> * The once-flag is smaller on Windows. In fact, unlike call_once, the
> behavior on Windows is equivalent to POSIX.
> * It has ticket #4225 fixed.
Could you explain how do you ensure that the code is thread safe?
> 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. What about making it depend on Boost.Chrono instead?
> * It offers more than I ever use. I don't need upgradeability.
pthread_rwlock_t are upgradable. Is there any constraint to don't make your Lightweight read/write mutex upgradable?
> 3. Lightweight thread-local storage for small POD values. Allows to
> store POD values of size up to sizeof(void*) with least possible
> overhead, memory and performance-vise.
> thread_specific< int > tls;
> Why not thread_specific_ptr:
> * thread_specific_ptr performance depends on the total number of ptrs
> within the application as it involves an additional lookup among them on
> access. thread_local does nothing more than abstracting away the native
> API for TLS, so it provides better performance.
> * thread_specific_ptr requires to dynamically allocate memory even for
> tiniest things, like bool or int. This is inconvenient and awkward,
> especially when memory and exception safety matters.
> 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?
> 4. shared_lock_guard. A light analogue to shared_lock, which allows to
> generate a more efficient code. Ticket #3567.
> As a part of this addition I would like to improve segregation of
> boost/thread/locks.hpp by extracting every component within it into a
> separate header in a new "locks" directory.
+1 for the separation. This should help to limit the dependencies.
> 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?
> 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?
Most of the synchronization features should work as well for interprocess. What about including all the synchronization features in a separated Synchro library?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk