This is the mail archive of the
mailing list for the glibc project.
Re: malloc patch for 2.2.4
> > 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
> 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:
22.214.171.124 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?