In Windows environment, is Boost’s scoped mutex using WinAPI’s critical sections, or something else?
In Windows environment, is Boost’s scoped mutex using WinAPI’s critical sections, or something else?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
In Windows environment, is Boost’s scoped mutex using WinAPI’s critical sections, or something else?
The current version of
boost::mutexuses neither a Win32CRITICAL_SECTION, nor a Win32 Mutex. Instead, it uses atomic operations and a Win32 Event for blocking waits.Older versions (boost 1.34.1 and prior) were a wrapper around
CRITICAL_SECTIONon Windows.Incidentally, the mutex itself is not scoped. The
boost::mutex::scoped_locktype and, in recent versions,boost::lock_guard<boost::mutex>andboost::unique_lock<boost::mutex>provide RAII wrappers for locking a mutex to ensure you don’t forget to unlock it.The
boost::lock_guard<>andboost::unique_lock<>templates work with any type withlock()andunlock()member functions, so you can use them with inter-process mutexes if desired.