Re: malloc patch for 2.2.4

[Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>]

> > From: Wolfram Gloger <Wolfram.Gloger@dent.med.uni-muenchen.de>
> > 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.

Thanks, I did not know that these existed, good.

> 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.

First, the ANSI/ISO standard for C still doesn't contain the word
thread or concurrency, so to argue on this base is questionable in any
direction.  My point was that it would be _bad_ to enable such a
re-read in the compiler.  It would seriously limit C's usefulness and
expressive power for threaded programming IMHO.

Second, I just discovered this in my draft of C9X:

5.1.2.3  Program execution
...
       [#5]  An  instance  of  each  object  with automatic storage
       duration is associated with each entry into its block.  Such
       an  object  exists  and retains its last-stored value during
       the execution of the block and while the block is  suspended
       (by a call of a function or receipt of a signal).

Doesn't this forbid a re-read from 'a' for 'tmp' even in the
single-thread, but possibly signal-interrupted case?

Regards,
Wolfram.