This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: malloc patch for 2.2.4


On Wed, Aug 22, 2001 at 02:03:08PM +0200, Wolfram Gloger wrote:
> Hello,
> 
> > 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.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]