This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: "memory" clobber in synchronization primitives
- To: "Thomas Bushnell, BSG" <tb@MIT.EDU>
- Subject: Re: "memory" clobber in synchronization primitives
- From: Jonathan Larmour <jlarmour@cygnus.co.uk>
- Date: Tue, 01 Sep 1998 01:22:49 +0100
- CC: roland@frob.com, drepper@cygnus.com, libc-hacker@gnu.org
- Organization: Cygnus Solutions Ltd.
- References: <199808312200.SAA18070@steve-dallas.mit.edu>
Thomas Bushnell, BSG wrote:
> Since (at least in GCC)
> any normal function call is a global memory barrier, it may arise seldom
> enough to be subtle and unclear. The pthreads synchronization primitives
> in linuxthreads are all implemented as normal functions (not macros or
> inlines), so the question has not yet had to be answered.
>
> This is right; if there is a function call, there is no need to add a
> memory clobber. But if there is an inlined function, or a macro, then
> a memory clobber should be there.
AIUI egcs now does global common subexpression analysis which means
statements can be reordered over function call boundaries. i.e. in the
simplest case where myvar is a non-volatile local:
myvar++;
foo();
myvar++;
egcs will now (I believe) do something like myvar+=2 after the call to
foo(). Of course this is designed so it shouldn't have any side-effects. But
I don't know the bit of code in question in glibc, so I think its possible
you might need the memory clobber anyway.
Jonathan L.
--
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK. Tel: +44 (1223) 728762
"Women marry hoping their husbands will change, men||Home e-mail: jifl @
marry hoping their wives never do. Both are rare." || jifvik.demon.co.uk
Help fight spam! http://spam.abuse.net/ These opinions are all my own fault