Brian Modra wrote:
> Hi,
> Is it possible that the gcc optimiser could re-order the following
> code:
> sem_wait(&mutex);
> bool different = val != buf_level;
> sem_post(&mutex);
> if (different) {
> ...
> e.g. to:
> sem_wait(&mutex);
> sem_post(&mutex);
> if (val != buf_level) {
> ...
> ???
>
> I've asked this question generally on comp.lang.c++.moderated
> The answer I have received is that although the standard does not
> specifically forbifd it, it won't be happening because it knows that
> code between sem_wait() and sem_post() need to stay within the
> "locked block". I've also been told that I can always look at the
> produced assembly, but that does not really help me, because there are
> thousands of far more complicated bits of code I've written using
> semaphores. I don't know what actually causes the optimiser
> re-ordering to kick in.
gcc won't do this, even though the C++ standard doesn't forbid it.
This is because the POSIX threads standard requires stricter behaviour
than the C++ standard, and we support POSIX. POSIX requires this to
work:
bool we_hold_a_lock;
...
if (we_hold_a_lock)
foo = shared_variable;
If you really want to know all the gory details, see _Threads Cannot
be Implemented as a Library_ at
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
Andrew.
