Sorry, you're right; I read too quickly. The mutex class was changed so that it uses a mutex if necessary (i.e., if it must be named--a feature that isn't in the current Boost.Thread) and a critical section otherwise. You're right that the try_mutex still uses a mutex, not a critical section, and a solution like what you describe is probably a good idea. However, why not call your TryCriticalInit() function using the Boost.Thread call_once() function? I'll work on something like this and look at timed_mutex when I move the mutex implementation from the thread_dev to the main branch. Mike Adal Chiriliuc wrote:
On Monday, March 22, 2004 Michael Glassford wrote:
For what it's worth, the version of Boost.Thread in the thread_dev branch of CVS already uses a critical section when possible. As time allows, I'm planning to review the code in the thread_dev branch, ask for comments, finish anything that isn't finished, and move it to the main branch piece by piece. I'm currently doing this (very slowly, I'm afraid) for the thread_specific_ptr and related classes.
This file? Sorry, but I have little CVS experience.
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/src...
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/src...
It does not do what I have suggested. try_mutex still uses a real mutex instead of a CRITICAL_SECTION on Windows NT.
I did not suggest to use a CRITICAL_SECTION when not supporting the trylock operation, this is already done. I suggested to check at runtime the operating system version and choose the best option.
Adal Chiriliuc
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost