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
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).
Regards,
Wolfram.