Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>

Subject: Re: [boost] [thread] Request review of new synchronisation object, boost::permit<>
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-05-07 10:31:04

2014-05-04 1:13 GMT+04:00 Niall Douglas <s_sourceforge_at_[hidden]>:

> Dear Boost,
>
> Review and commentary upon a proposed new Boost object,
> boost::permit<> is invited.
>

I've just started to read the documentation and that's what looks wrong:
...

And the compiler's optimiser is permitted by the standard to believe that
result has not changed between its initialisation and the first test of its
value, so in fact the optimiser could compile this instead by eliding the
first test of result under the assumption that the predicate will always be
false for its first execution:

do {
    wait(guard);} while(!pred());

...

This can not happen because thread constructor is a `release` operation:

// main thread
int result=0;
boost::thread(f); // release [2]
boost::unique_lock<decltype(lock)> guard(lock); // acquire [1]
done.wait(guard, [&result] { return result!=0; });

// new thread
// acquire - from thread constructor [2]
boost::lock_guard<decltype(lock)> guard(lock); acquire [1]
result=78;
// release [1]

Compiler is prohibited from moving non-atomic stores past the atomic
store-release or perform non-atomic loads earlier than the atomic
load-acquire.

[1] ISO C++11 30.4.1.2 Mutex types: Synchronization: Prior unlock()
operations on the same object shall synchronize with (1.10) this operation.

[2] ISO C++11 30.3.1.2 thread constructors: Synchronization: The completion
of the invocation of the constructor synchronizes with the beginning of the
invocation of the copy of f.

--
Best regards,
Antony Polukhin