On Thu, Mar 31, 2011 at 7:49 PM, Steven Watanabe <watanabesj@gmail.com>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