This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: malloc patch for 2.2.4
> Date: Thu, 23 Aug 2001 14:20:18 +0200 (MDT)
> From: Wolfram Gloger <Wolfram.Gloger@dent.med.uni-muenchen.de>
> CC: libc-alpha@sources.redhat.com
>
> > > 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.
Of course, they cause a huge performance penalty, but that's a
consequence of getting the behaviour you want. It's usually much
better to just mark the appropriate variables 'volatile' explicitly.
> > 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.
I wasn't here talking about what ISO requires---as you say, threads
are not dealt with by the C standard. I was saying what the compiler
will actually do.
> 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?
No, because reading any static variable, or writing any static
variable other than one of type 'volatile sig_atomic_t', from a signal
handler causes undefined behaviour---s. 7.14.1.1, paragraph 5 in the
final standard. Basically, all asynchronous signal handlers must look
like
static volatile sig_atomic_t flag;
void handler (int x)
{
flag = 1;
}
In this case, 'a' is not declared volatile and so it can't possibly be
a 'volatile sig_atomic_t'.
--
- Geoffrey Keating <geoffk@geoffk.org>