GAtomic int finals (#63621)

[Tim Janik <timj gtk org>]

hi sebastian,

this is an attempt to sort out the remaining issues in the
atomic int patch in public (mostly because it involves API design).

first off, thank you very much for preparing the patches to make this
happen, the latest version:
	http://bugs.gnome.org/showattachment.cgi?attach_id=24520
looks very promising.


on the technical side, i have one reamining issue. there're a couple
discussions on the net that seem to suggest we won't be able to ignore
memory barrier issues forever in the API we introduce:

http://www.ussg.iu.edu/hypermail/linux/kernel/0110.1/0725.html
        (alpha can reorder and coalesce read and write requests through
        several cache layers)
http://www.ussg.iu.edu/hypermail/linux/kernel/0110.1/0737.html
        (linus on needing read memory barriers)

so if we run into issues due to lack of memory barriers, there're two options:
1) we add rmb/wmb/mb to the API and expect people to use them appropriately
2) we add the barriers to out atomic primitives

(1) is unlikely to work out properly (complexity, portability, hard to debug,
requires knowledge about multiple architectures),
(2) requires an ordinary getter that is used exclusively for access, so
an rmb can be added if required by a platform.

since a getter can be a simple inlined read, it doesn't cost us anything
now (except API and mandatory use), so i strongly opt for adding it.


on to the API names.

> I've renamed g_atomic_int_exchange_and_add to
> g_atomic_int_get_and_add. It's shorter and adheres more to the GLib
> naming scheme and is more correct (Nothing is exchanged here).

i don't think g_atomic_int_get_and_add() is an improvement. exchange_and_add()
is a pretty established name, we should stick with that. and in contrast to
get_and_add(), it tells me that the value returned is the int *before* the
add, not after. (so in effect, *i* do see what's exchanged here ;).

the API involved with atomic operations should be kept as small as possible,
that way it stays simple and avoids confusion about what primitives to use.
that is, we shouldn't provide g_atomic_int_inc() and g_atomic_int_dec_and_test().


with the above 3 issues sorted out, the patch is ready to go into CVS, making
way for a variety of other glib improvements/optimizations ;)

---
ciaoTJ