This is the mail archive of the
mailing list for the glibc project.
Re: malloc patch for 2.2.4
> 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.