"memory" clobber in synchronization primitives

Jonathan Larmour jlarmour@cygnus.co.uk
Mon Aug 31 17:23:00 GMT 1998


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



More information about the Libc-hacker mailing list