This is the mail archive of the
mailing list for the glibc project.
Re: malloc patch for 2.2.4
On Wed, Aug 22, 2001 at 02:03:08PM +0200, Wolfram Gloger wrote:
> > Why? If you had some synchronization primitive in between (like mutex lock)
> > and compiler could do this accross the synchronization primitive, then it
> > would of course be unsuitable for threaded programs,
> Sure, that would even contradict the standard.
> > but the compiler will
> > not reread it accross mutexes etc. - as soon as you call some function which
> > might clobber global data (ie. non-const, non-pure)
> Ahem, when I am running a threaded program, some other thread (that is
> "me", too :-), will potentially be executing such a function at any
> time. At least, any compiler worth its salt should assume that. That
> is my point.
> Note: I don't need synchronized access, for that a mutex / a full
> memory barrier would be required. In this case, the mutex would kill
> performance for sure. I just want atomic read access to _whatever_
> state the pointer is in.
Then either make the memory variable (like __malloc_hook) volatile, or use
the asm ("" : "=r" (hook) : "0" (hook)); trick. The latter is cheaper.