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 away. 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 programmers' understanding. Andrew.
