Re: Any plans for glib to contain atomic compare/exchange?

["Peter \"Firefly\" Lund" <firefly diku dk>]

On Wed, 30 Jul 2003, Mike Hearn wrote:

> Sorry, I don't know anything about non-x86 SMP architectures :( Why

GTK+/Gnome is supposed to run on other machines than just the typical x86
PC.

> would you need those?

To make changes to memory visible to other CPUs (for example changes to
the pointers that constitute the backbone of linked lists).

Some architectures have a much weaker memory order than the x86 so memory
barrier instructions are necessary (memory reads/writes are not reordered
across memory barriers).

The Alpha is one such architecture.  The IA-64 is another.

To top things up (is that the right idiom?), no two architectures even
seem to implement the same memory ordering so they don't even have the
same requirements as to where the barriers must be put!

(I.e. some architectures implicitly disallows reordering of /some/ memory
accesses whereas others require explicit barriers everywhere.  If you
always use barriers every time a hypothetical machine with the loosest
possible memory ordering would require a barrier, you'll always be safe.
I think the Alpha actually has that loose a memory order, except that the
size of the reordering buffer in the practical implementations put a
small, finite (and different!) limit on the number of outstanding memory
transactions)

> What exactly would they do? Just wrap mprotect
> etc?

No.  They are instructions, not system calls.

(x86 actually has memory barrier instructions, too.  They are needed not
as much for SMP code as for device drivers)

> > (and wouldn't it be too hard to do for most "programmers" anyway?  Those
> > precious few who can do it right can probably do it without glib --
> > probably the easiest way is to steal/adapt similar code from the Linux
> > kernel)
>
> Wouldn't what be too hard to do? Using them? If so then I don't think
> so. Sure maybe this kind of thread stuff is a bit advanced for a lot of
> people, but that doesn't make it any less useful.

Most people who post in gtk-app-devel-list barely know C.  Of those who
do, pointers (especially function pointers) seem to be advanced
higher-order magic.

I think it is better to have simple data structures in glib (and tell
people to use mutexes to protect them if they use threads) than to give
them more sharp tools to cut themselves on.

The people who know how to use these things correctly will also be able to
code them up if they need them.

Please note that despite your pretty impressive record (with Wine, for
example) you didn't know about memory barriers either! :)

-Peter