Re: GAtomic int finals (#63621)

[Sebastian Wilhelmi <seppi seppi de>]

Hi Tim,

> > Ah, I see, you get to the same conclusion. Actually it might be wise to
> > export a memory barrier (a full one, further optimizing in read/write
> > seems to be too much) for glib's internal use. We should however not
> > export it. That would allow to replace the current lightly crude "double
> > checked locking" check in configure.in by proper memory barriers in
> > gthread.c.
> 
> i don't think a memory barrier for glibs internal use is a good idea.
> for one, coding atomic ints for glib shouldn't be anymore complicated than
> coding them outside glib ;) and for another, if a getter solves our memory
> barrier problems why export one then? (let alone that a getter can come with
> a comparatively cheap rmb in cnstrast to a fat rmb+wmb)

Actually, if I'm not completely mistaken, an rmb is more expensive, than
an wmb. E.g. on all libc archs, the full mb is equal to the rmb (Ok, on
powerpc64, they use lwsync for rmb instead of sync for mb), whereas the
wmb is simpler. And that is also plausible, as a write barrier does not
have to care for data outside the processor cache, whereas the read
barrier has to make sure, that other processors caches are consistent
with the main memory (What consistency means here, is defined by the
memory model. Lets not get into that for now to avoid too many false
assumptions ;-)

Ciao,
Sebastian
-- 
Sebastian Wilhelmi                 |            här ovanför alla molnen
mailto:seppi seppi de              |     är himmlen så förunderligt blå
http://seppi.de                    |