----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, July 04, 2010 7:15 PM Subject: [boost] [thread] A few submissions
Hi,
I would like to propose the following components for inclusion into Boost.Thread:
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() { BOOST_LOG_ONCE_BLOCK() { 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 all.
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.
<http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost/log/detail/thread_specific.hpp> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/log/src/thread_specific.cpp>
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?
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? Best, Vicente