Re: GAtomic int finals (#63621)

[Manish Singh <yosh gimp org>]

On Fri, Feb 20, 2004 at 02:06:57AM +0100, Tim Janik wrote:
> 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.

I agree, a getter would be good.
 
> 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().

For this one I disagree. g_atomic_int_inc() and g_atomic_int_dec_and_test()
etc. make for better code readability, since one can easily tell at a glance
what's going on. Also, possibly using add/sub by one instructions are an
efficiency gain, but no idea if it's measurable.

The Linux kernel API has a number of primitives, and it's pretty clear what
they all do.

-Yosh