Re: GAtomic int finals (#63621)

[Owen Taylor <otaylor redhat com>]

On Fri, 2004-02-20 at 08:29, Tim Janik wrote:

> > > 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 ;).
> >
> > Doesn't sound very convincing. We need an arbiter. Let Owen decide.
> 
> ok, will prompt him.

I don't have a big opinion here, but my basic reasoning would be:

 - The operation is a bit "odd" - you aren't going to know how to use it
   unless you've seen it before.
 - So sticking to the name found elsewhere is better than trying to 
   come up with a name that makes the operation obvious.

> > > 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().
> >
> > I would really like to keep both, even if they are one-liners. They make
> > the reference counting code easier to read.
> 
> the gnits i really have with your variants are:
> - #define g_atomic_int_inc(atomic) (g_atomic_int_add ((atomic), 1))
>   i pretty much know that inc amounts to add(,1) so i don't see a clear advantage here
> - #define g_atomic_int_dec_and_test(atomic) (g_atomic_int_get_and_add ((atomic), -1) == 1)
>   a) for this, i'll have to lookup your definition everytime i use it, to
>      figure whether you test for ==1 or >1
>   b) looking at how the stl does refcounting for strings, they support a -1 count
>      which means orphaned, can-be-freed, cant-be-referenced. i could quite possibly
>      use something like that for GObject, in that light, get_and_add(,-1)==1 becomes
>      useless, if not confusing.
> 
> yosh is in favour of these also, owen?

I like having the atom_inc / atom_dec_and_test since I think these are
the operations that people will do frequently. Yes, there might be cases
where people want something else, but these will be the frequent ones.

And having their definitions in the header file will actually help
people figure out what they need to do when they want to do something
different.

> > > 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 ;)
> >
> > Making way for convoluted ways to shoot in our feet.

Someone does need to contact the libc maintainers and maybe the FSF
before we ship a final release with the big macros in it. I guess I
should take responsibility for bouncing this off of Ulrich Drepper.

Regards,
							Owen