----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, July 04, 2010 11:49 PM Subject: Re: [boost] [thread] A few submissions
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>
Oups. I missed a sentence.
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.
Then if I understand your thread_specific class doesn't have any issues with dynamically-loaded modules, isn't it? If this is the case, could you clarify how your class avoids the problem?
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.
OK, I see. This seems a valid use case.
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?
packaging, documentation, tests, ... Thanks, Vicente