Performance characteristics of Boost mutex
Hi all, I am detecting some lock contention in my application, and while reading up on this I came across the concept of lightweight mutexes versus supposedly non-lightweight mutexes. I am wondering, can Boosts non-recursive mutex implementation be considered lightweight? In boost/detail I see lightweight_mutex. Should I be using that? I need no interprocess support here, and I want the lock to be as fast as possible. If I do decide to use lightweight_mutex, is it compatible with the regular non-recursive Boost mutex so that I can use it with higher level classes like lock guard, condition variables, barriers etc? Thanks in advance for any insight. Kind regards, Philip Bennefall
Philip Bennefall wrote:
Hi all,
I am detecting some lock contention in my application, and while reading up on this I came across the concept of lightweight mutexes versus supposedly non-lightweight mutexes. I am wondering, can Boosts non-recursive mutex implementation be considered lightweight? In boost/detail I see lightweight_mutex. Should I be using that?
Probably not. detail::lightweight_mutex is merely a thin wrapper over CRITICAL_SECTION on Windows and pthread_mutex on POSIX. It's "lightweight" only in the sense that it doesn't require the user to link against a library (Boost.Thread). In general, it doesn't make much sense to talk about a "lightweight" mutex if you're talking performance. The "weight" of the mutex doesn't - in general - have much to do with its performance (nowadays).
On 10/17/2014 10:34 PM, Peter Dimov wrote:
Philip Bennefall wrote:
Hi all,
I am detecting some lock contention in my application, and while reading up on this I came across the concept of lightweight mutexes versus supposedly non-lightweight mutexes. I am wondering, can Boosts non-recursive mutex implementation be considered lightweight? In boost/detail I see lightweight_mutex. Should I be using that? Probably not.
detail::lightweight_mutex is merely a thin wrapper over CRITICAL_SECTION on Windows and pthread_mutex on POSIX. It's "lightweight" only in the sense that it doesn't require the user to link against a library (Boost.Thread).
In general, it doesn't make much sense to talk about a "lightweight" mutex if you're talking performance. The "weight" of the mutex doesn't - in general - have much to do with its performance (nowadays).
Hi Peter, I see that Boost thread, since a few years ago from what I can tell, has its own mutex implementation based on a Windows event where as before it merely used critical sections. I am curious to know what the reasoning behind this change was? In short, what are the pros and cons of using critical sections directly versus the implementation in Boost thread? Kind regards, Philip Bennefall
Philip Bennefall wrote:
Hi Peter,
I see that Boost thread, since a few years ago from what I can tell, has its own mutex implementation based on a Windows event where as before it merely used critical sections. I am curious to know what the reasoning behind this change was?
Hi Philip, CRITICAL_SECTIONs do not provide timed locking, and did not, at the time, provide try-lock (TryEnterCriticalSection was not available on pre-XP, and pre-XP platforms were still important in those days.) In addition, Boost.Thread's alternative implementation was, at the time, actually superior in performance to Windows's one. Today, the built-in CRITICAL_SECTION in Vista/7/8 can probably hold its own, and the slim reader-writer lock in exclusive mode will likely be a very good performer as well. (CRITICAL_SECTION is also recursive, which may not be a good choice for a non-recursive mutex, even though it's technically allowed.)
On 10/17/2014 4:34 PM, Peter Dimov wrote:
Philip Bennefall wrote:
Hi all,
I am detecting some lock contention in my application, and while reading up on this I came across the concept of lightweight mutexes versus supposedly non-lightweight mutexes. I am wondering, can Boosts non-recursive mutex implementation be considered lightweight? In boost/detail I see lightweight_mutex. Should I be using that?
Probably not.
detail::lightweight_mutex is merely a thin wrapper over CRITICAL_SECTION on Windows and pthread_mutex on POSIX. It's "lightweight" only in the sense that it doesn't require the user to link against a library (Boost.Thread).
In general, it doesn't make much sense to talk about a "lightweight" mutex if you're talking performance. The "weight" of the mutex doesn't - in general - have much to do with its performance (nowadays).
Nonetheless on Windows CRITICAL_SECTION is quite a bit faster than the mutex object, probably because it is intraprocess whereas Window mutex objects are interprocess.
participants (3)
-
Edward Diener -
Peter Dimov -
Philip Bennefall