Re: gcc reordering

[Andrew Haley <aph at redhat dot com>]

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.