Re: [Boost-users] [Thread] Semantics regarding memory barrier/happens-before relationship

Subject: Re: [Boost-users] [Thread] Semantics regarding memory barrier/happens-before relationship
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-11-10 01:45:54

On 11/8/11, Falk S. <falk-o-mat_at_[hidden]> wrote:
> Hi,
>
> I have read an article on Dr.Dobbs
> (http://drdobbs.com/cpp/184401518?pgno=3) about the Boost Thread Library
> and a given example quoted below raised a question to me regarding race
> condition safety (stripped).
>> |const| |int| |BUF_SIZE = 10;|
>> |const| |int| |ITERS = 100;|
>>
>> |boost::mutex io_mutex;|
>>
>> |class| |buffer|
>> |{|
>> |public||:|
>> |  ||typedef| |boost::mutex::scoped_lock|
>> |    ||scoped_lock;   |||
> |[..]|
>>
>> |  ||int| |get()|
>> |  ||{|
>> |    ||scoped_lock lk(mutex);|
>> |    ||if| |(full == 0)|
>> |    ||{|

> I wonder if it is possible the compiler produces optimised code and
> checking the member 'full' before creating the scoped lock. Imagine two
> threads calling/entering method buffer.get. That would lead to a
> possible race condition. Why is this not possible and how is this
> guaranteed with current C++ Compilers?
>

Technically there is no guarantee, but it always works.  It works
because either:

- the compiler recognizes the underlying OS level calls (or compiler
level intrinsics) inside the inlined constructor of scoped_lock() and
knows not to optimize around them
- the compiler sees a library call (either the constructor or the a
library call from the inlined constructor) and says "I have no idea
what that library call does, I better not optimize around it"

typically the second.

Tony