This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PATCH: Add memory barrier to malloc
On Tue, May 06, 2003 at 03:43:19PM -0000, Wolfram Gloger wrote:
> Hi,
>
> Sorry for coming in late, I'm on vacation ATM.
>
> > > >>>>>>"H.J. Lu" == H J Lu <hjl@lucon.org> writes:
> > > >
> > > > H.J. Lu> --- libc/malloc/arena.c.barrier 2002-12-26 16:36:41.000000000 -0800
> > > > H.J. Lu> +++ libc/malloc/arena.c 2003-05-03 23:56:59.000000000 -0700
> > > > H.J. Lu> @@ -758,6 +758,7 @@ arena_get2(a_tsd, size) mstate a_tsd; si
> > > > H.J. Lu> /* Add the new arena to the global list. */
> > > > H.J. Lu> (void)mutex_lock(&list_lock);
> > > > H.J. Lu> a->next = main_arena.next;
> > > > H.J. Lu> + atomic_write_barrier ();
> > > > H.J. Lu> main_arena.next = a;
> > > > H.J. Lu> (void)mutex_unlock(&list_lock);
> > > >
> > > > Why would a barrier be needed inside a critical section ? Aren't POSIX
> > > > memory model guarantees sufficient ?
> > >
> > > I guess list_lock doesn't protect accesses to main_arena?
> >
> > That is currect. list_lock isn't held when walking through linked list
> > for available arenas.
>
> True, but note that the list is only _read_ without the lock held
> _and_ it does not/should not matter whether the new value _or_ the old
> value is obtained when walking the list.
>
> If the patch above makes a difference it just shows that read access
> to a pointer in memory isn't atomic on ia64. Is that actually the
> case? (There may be other places in malloc where atomic read access
> to a pointer is assumed).
It is very possible. I am not a hardware person. I was told it only
happened on MP system of certain CPU arch, not limited to ia64. Please
do
# cd linuxthreads/sysdeps
# find -name pt-machine.h | xargs grep MEMORY_BARRIER
Any arch defines it may require this change. I think atomic_write_barrier
makes sure every CPU sees the same data at the same time.
H.J.