10

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

ThinkingStiff
  • 64,767
  • 30
  • 146
  • 239
nhaa123
  • 9,570
  • 11
  • 42
  • 63

2 Answers2

21

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.

Anthony Williams
  • 66,628
  • 14
  • 133
  • 155
  • This is probably almost / just as efficient as a Win32 Critical Section? – unixman83 Dec 18 '10 at 10:06
  • @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. – gbjbaanb May 10 '11 at 08:47
  • 4
    @gbjbaanb 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. – Anthony Williams May 10 '11 at 12:44
  • 1
    by "Win32 Event for blocking waits" do mean WaitForSingleObject function ? – Guillaume Paris Aug 08 '11 at 21:05
  • @Guillaume07: Yes, it uses `WaitForSingleObject` on a win32 event (created with `CreateEvent`) when doing a blocking wait. – Anthony Williams Aug 09 '11 at 08:41
3

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.

Jason S
  • 184,598
  • 164
  • 608
  • 970
  • Yes, these I already knew. Hmm, guess I need to look into the actual source later on.. – nhaa123 May 18 '09 at 13:04
  • 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. – Jason S May 18 '09 at 13:06
  • 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. – Jason S May 18 '09 at 14:37
  • 5
    However, the docs for Boost::mutex clearly say "These are all thread-level mutexes; interprocess mutexes are not supported". – Kylotan Jul 08 '09 at 16:23
  • 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. http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.mutexes.mutexes_interprocess_mutexes – Jason S Jul 08 '09 at 16:55
  • 1
    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. – Kylotan Jul 09 '09 at 15:07
  • :shrug: I don't see why it's more natural to assume the Boost::thread library than the Boost::interprocess library... but whatever. – Jason S Jul 09 '09 at 18:17