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-13 15:32:20

On Mon, Jan 14, 2013 at 12:04 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> On Sun, Jan 13, 2013 at 11:44 PM, Andrey Semashev
> <andrey.semashev_at_[hidden]> wrote:
>> On Sun, Jan 13, 2013 at 11:15 PM, Vicente J. Botet Escriba
>> <vicente.botet_at_[hidden]> wrote:
>>>
>>> I believed it also but the mutex shouldn't be locked while doing
>>> notifications, only when you change the condition and when you wait for the
>>> condition to be notified.
>>
>> Looking at the code now it seems there is a potential race condition.
>> The commit or rollback can set the flag and issue the broadcast just
>> before the enter method acquires the lock and blocks in the cv.
>>
>> I suppose there should be a second check for the flag value under the
>> lock in the enter_once_region method. The locks in commit and rollback
>> functions can be removed altogether then.
>
> I attached the updated once.cpp.

No, that code is not correct either. The lock in commit and rollback
functions *is* needed and it *must* cover both the store and broadcast
exactly to prevent missed notifications. Otherwise thread A can check
for the flag value but not yet enter pthread_cond_wait and thread B
can store the new flag value and issue pthread_cond_broadcast.

I attached the corrected code. Apologies for the confusion.