This is the mail archive of the
mailing list for the GCC project.
Re: Optimization of conditional access to globals: thread-unsafe?
- From: skaller <skaller at users dot sourceforge dot net>
- To: Bart Van Assche <bart dot vanassche at gmail dot com>
- Cc: Andrew Haley <aph-gcc at littlepinkcloud dot com>, gcc at gcc dot gnu dot org, Andrew Pinski <pinskia at gmail dot com>, Tomash Brechko <tomash dot brechko at gmail dot com>
- Date: Sat, 27 Oct 2007 02:04:25 +1000
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <email@example.com> <firstname.lastname@example.org>
On Fri, 2007-10-26 at 16:05 +0200, Bart Van Assche wrote:
> On 10/22/07, Andrew Haley <aph-gcc at littlepinkcloud dot COM> wrote:
> I agree that according to the C and C++ language standards, any
> variable shared over threads should be declared volatile.
No, they say nothing about multi-threaded programs.
> 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.
> Maybe it is a good idea to add the following function attributes in
> gcc: __attribute__((acquire)) and __attribute__((release)) ? A
> refinement of these attributes would be to allow to specify not only
> the acquire/release attributes, but also the memory locations to which
> the acquire and release apply (pthreads synchronization functions
> always apply to all memory locations).
That sounds quite interesting!
But, now you should continue this idea. You are suggesting
primitives to attach to 'code' but then only say 'functions'.
What about plain old statements? Expressions?
Now you need to specify a calculus for these properties.
I think this idea is really hot .. it's so much simpler
and fine-grained that just having a mutex.
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net