Re: malloc patch for 2.2.4

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Wed, 22 Aug 2001 14:03:08 +0200 (MDT)
> From: Wolfram Gloger <Wolfram.Gloger@dent.med.uni-muenchen.de>
> CC: schwab@suse.de, libc-alpha@sources.redhat.com, brianmc1@us.ibm.com,
>         wg@malloc.de
> 
> Hello,
> 
> > Why? If you had some synchronization primitive in between (like mutex lock)
> > and compiler could do this accross the synchronization primitive, then it
> > would of course be unsuitable for threaded programs,
> 
> Sure, that would even contradict the standard.
> 
> > but the compiler will
> > not reread it accross mutexes etc. - as soon as you call some function which
> > might clobber global data (ie. non-const, non-pure)
> 
> Ahem, when I am running a threaded program, some other thread (that is
> "me", too :-), will potentially be executing such a function at any
> time.  At least, any compiler worth its salt should assume that.  That
> is my point.

There are flags for this.  They are

-fvolatile
-fvolatile-static
-fvolatile-global

depending on which things you think might be changed asynchronously.
Otherwise, the compiler assumes that the code it generates is the only
thing changing nonvolatile memory.

> Note: I don't need synchronized access, for that a mutex / a full
> memory barrier would be required.  In this case, the mutex would kill
> performance for sure.  I just want atomic read access to _whatever_
> state the pointer is in.

In the case of code like

static int a;

{
  int tmp;

  tmp = a;
  if (tmp == 0)
    {
      if (tmp != 0)
        abort ();
    }
}

Where 'a' may be changed during execution of the code fragment, there
is no guarantee that abort() will not be called.  The compiler may,
depending on many possible things, decide to re-read from 'a' rather
than using a temporary.  [Of course, for this simple example, the
abort() is more likely to be optimised out altogether, but that could
happen even if the temporary was not used.]

-- 
- Geoffrey Keating <geoffk@geoffk.org>