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?
The once flag is only modified when an internal mutex is locked. If a thread entered the once-block, all other threads are blocked in a condition variable. Take a look at the code for more details.
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.
That's right. You want more features - you pay with longer compile times.
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.
I also want to shorten compile times.
* 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.
pthread_rwlock_rdlock(mutex); /* upgrade the mutex*/
pthread_rwlock_wrlock(mutex);
This us undefined behavior: <http://opengroup.org/onlinepubs/007908775/xsh/pthread_rwlock_wrlock.html>
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. :)
Do you mean that at the end the C++0x standard will have problems with dynamically-loaded modules? :(
I mean that current compilers have this problem. Whether the C++0x-conforming implementations will solve it or not is yet to be seen.
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 use it in logger features in Boost.Log. Say, we have N features that derive from one another and implement an operation and require a certain concurrency protection. Each feature can require a different protection. template< typename T > struct feature1 : T { typedef typename strictest_lock< typename T::op_lock, shared_lock< ... > >::type op_lock; void op(); // requires shared_lock and calls T::op }; template< typename T > struct feature2 : T { typedef typename strictest_lock< typename T::op_lock, unique_lock< ... > >::type op_lock; void op(); // requires unique_lock and calls T::op }; Now, if we instantiate feature1< feature2< ... > >, the resulting compound will have the op_lock type that satisfies all features.
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.
What stops it from being a mini-review?
once-blocks, no, but why not rw mutexes and shared_lock_guard?
rw mutex is process-local and I'd like to keep it that way. Regarding lock types, I have no strong opinion, but I have no problems with using locks from Boost.Thread on any type that models the appropriate concepts.
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?
It's a question of finding the information about the lock types. If Boost.Interprocess docs have a link to Boost.Thread locks, then yes, I would find it.