Re: [Boost-users] [boost::mutex] Do they block or wait?

Subject: Re: [Boost-users] [boost::mutex] Do they block or wait?
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2011-03-31 14:21:29

On Thu, Mar 31, 2011 at 7:49 PM, Steven Watanabe <watanabesj_at_[hidden]>wrote:

> AMDG
>
>
> On 03/31/2011 09:55 AM, Panagiotis Foteinos wrote:
>
>> I looked into the documentation, but it is still unclear to me.
>>
>> [...]
>
> boost's locking mechanism
>> blocking or spinning?
>>
>>
> It's an implementation detail.  You realize that the
> two aren't necessarily mutually exclusive?  Anyway,
> Boost.Thread does block on an Event.  A spin-lock
> only makes sense on a multi-core system.
>
> In Christ,
> Steven Watanabe
>

As Steven pointed out it is an implementation detail and these two concepts
might be used together  (primarily for optimization). Switching to kernel
mode (e.g. dealing with kernel objects like event, mutex, semaphore through
system calls) is a very time costly operation, therefore some libs provide
spinning optimizations, which do spinning (for some few cpu cycles) and if
they are still unable to acquire a lock, they make a system call which
changes into the kernel mode and finally puts the thread into the blocked
state if the object is still not available (signaled, unlocked etc). But
even so it is not black and white in the concurrency world. :( Some would
like to achieve speed through such an optimization others would like to get
rid of such an optimization. A good example might be an embedded app running
on a battery driven HW, where energy plays a major role. Here wasting CPU
cycles for speed optimization might not be a good idea... But anyway that
should be separately evaluated.

With Kind Regards,
Ovanes