Is there a difference between Boost's scoped mutex and WinAPi's critical section?

Question

In Windows environment, is Boost's scoped mutex using WinAPI's critical sections, or something else?

Staceestacey

You didn't take a look into the Boost source code, did you? :) – Exoskeleton

I'm in a location where I have no access to it :( – Staceestacey

You need Internet access for both Stack Overflow and Boost sources. svn.boost.org/svn/boost/trunk – Calliope

Answer 1

The current version of boost::mutex uses neither a Win32 CRITICAL_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_SECTION on Windows.

Incidentally, the mutex itself is not scoped. The boost::mutex::scoped_lock type and, in recent versions, boost::lock_guard<boost::mutex> and boost::unique_lock<boost::mutex> provide RAII wrappers for locking a mutex to ensure you don't forget to unlock it.

The boost::lock_guard<> and boost::unique_lock<> templates work with any type with lock() and unlock() member functions, so you can use them with inter-process mutexes if desired.

Galvin

This is probably almost / just as efficient as a Win32 Critical Section? – Athanasia

@unixman83: I doubt it, a critical section is fast because it is in-process only, you can't use it between processes. It isn't a kernel object, but Win32 Events are. So I would assume this isn't as fast as a CS. – Inimical

@Inimical Have you timed it? Note that boost::mutex only resorts to using the event if there is contention --- the "fast path" uses atomic ops only. – Galvin

by "Win32 Event for blocking waits" do mean WaitForSingleObject function ? – Heptavalent

@Guillaume07: Yes, it uses WaitForSingleObject on a win32 event (created with CreateEvent) when doing a blocking wait. – Galvin

Answer 2

Win32's CRITICAL_SECTION can only be used among the threads of a single process. If you need to use something between processes, you need a mutex. Boost says nothing about critical sections so I would assume it is using mutexes.

"scoped" just means it has a wrapper that uses RAII to automatically unlock the mutex at the end of a particular scope.

Atmosphere

Yes, these I already knew. Hmm, guess I need to look into the actual source later on.. – Staceestacey

If they call it a "mutex", and do not mention the phrase "critical section" assume with very high probability it is not a critical section. – Atmosphere

Boost::interprocess is reputable enough that I think that way about it. Clarity is important. If it were someone's independent library I'm not sure I'd be as confident. – Atmosphere

However, the docs for Boost::mutex clearly say "These are all thread-level mutexes; interprocess mutexes are not supported". – Neri

WTF? OP says nothing about the particular type of mutex, only asked about scoping. There is interprocess_mutex and named_mutex. Try reading the docs yourself. boost.org/doc/libs/1_35_0/doc/html/interprocess/… – Atmosphere

The original poster asked about a mutex in Boost, so it's natural to assume this refers to Boost::mutex rather than some more specific mutex. This is part of the thread library rather than the interprocess library, and in the past did accordingly map to a critical section on Win32 rather than an OS-level mutex. Thus "I would assume it is using mutexes" is a reasonable assumption but a false one in this case. Even if the OP meant a different kind of mutex, this fact means that the general assumption does not apply universally. – Neri

:shrug: I don't see why it's more natural to assume the Boost::thread library than the Boost::interprocess library... but whatever. – Atmosphere