This is the mail archive of the
mailing list for the GCC project.
Re: Optimization of conditional access to globals: thread-unsafe?
- From: Andrew Haley <aph-gcc at littlepinkcloud dot COM>
- To: "Bart Van Assche" <bart dot vanassche at gmail dot com>
- Cc: gcc at gcc dot gnu dot org, "Andrew Pinski" <pinskia at gmail dot com>, "Tomash Brechko" <tomash dot brechko at gmail dot com>
- Date: Fri, 26 Oct 2007 16:09:15 +0100
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <email@example.com> <firstname.lastname@example.org>
Bart Van Assche writes:
> On 10/22/07, Andrew Haley <aph-gcc at littlepinkcloud dot COM> wrote:
> > The core problem here seems to be that the "C with threads" memory
> > model isn't sufficiently well-defined to make a determination
> > possible. You're assuming that you have no responsibility to mark
> > shared memory protected by a mutex as volatile, but I know of nothing
> > in the C standard that makes such a guarantee. A prudent programmer
> > will make conservative assumptions.
> My opinion is that it should be possible to declare whether C/C++
> code has acquire, release or acquire+release semantics. The fact
> that code has acquire semantics means that no subsequent load or
> store operations may be moved in front of that code, and the fact
> that code has release semantics means that no preceding load or
> store operations may be moved past that code. Adding definitions
> for acquire and release semantics in pthread.h would help a
> lot. E.g. pthread_mutex_lock() should be declared to have acquire
> semantics, and pthread_mutex_unlock() should be declared to have
> release semantics.
Hmmm. This is an interesting idea, but it sounds to me as though it's
somewhat at variance with what is proposed by the C++ threads working
group. In any case, gcc will certainly implement whatever the
standards committees come up with, but that is probably two years
Right now the question is whether or not gcc will produce thread-safe
code according to some memory model, rather than any specific details
about what that model should be.
IMO, we need to move rapidly towards tracking the proposed model from
the C++ threads working paper. This would at least provide a
reasonably sane model that corresponds with most thread and kernel