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?
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 all.
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 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. :)
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.