Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?

Subject: Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-01-14 02:46:30

On Mon, Jan 14, 2013 at 11:24 AM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> Le 14/01/13 04:23, Andrey Semashev a écrit :
>
>> 1. You have the race condition I described in my previous post. The
>> broadcast is missed if it happens when the other thread is executing
>> at **** position.
>
> I don't think so. The thread B has notified a commit in C*** or rollback in
> R***, the thread A could not be in //**** as the access to the flag is
> protected with the lock.

Ok, I'll leave this to you although I'm still not quite sure this is
safe. I'll have to examine the algorithm closer later to resolve all
my doubts.

>> 2. If you use the double-check pattern with the lock, you don't need
>> to CAS the flag.
>
> Well this was the issue with the Trac ticket. The first check works only if
> T is such that the load/save is atomic. Maybe the access to the atomic flag
> inside the lock protected part could be relaxed I don't know all the
> possibilities of Boost.Atomic.

All loads and stores of atomic<> are atomic. The problem of split
loads and stores should never occur when atomic<> is used, otherwise
there is a severe bug in Boost.Atomic. Using CAS instead of a
load/store does not make this guarantee any stronger. Note that this
guarantee does not depend on whether the operation is done under lock
or not.

>> 3. I think your code will have worse performance because you lock the
>> mutex whenever you are about to enter the execution block while mine
>> code will only lock in case of contention. This difference is not in
>> the most performance critical path but it still exists. However, I
>> didn't perform any tests to confirm that.
>>
> I agree. But the condition variable needs that the code changing/getting the
> protect data needs to be protected with the same mutex that is used on the
> wait.

Yes, but not necessarily every modification of the control flag has to
be protected.

> IMHO, your previous implementation failed to do that as every access to the
> once flag in enter_once_region was not protected.

Yes, that was a valid optimization. The flag is checked the second
time under the lock just before entering the wait on the condition
variable. This keeps the algorithm correct while allowing to remove
the lock from the fast path.