This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]