Re: Atomic Ints (Was: GObject thread safety)

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Alex,

> > I've for some time now wanted to include that and given, how long the
> > GLib API
> > of 2.0 will be fixed this indeed looks like a valuable addition.
> > Until now I hesitated, because:
> > 1) Its will add much asm-code-snippets to glib. That might prove hard > >    to maintain.
> > 2) I do not know of any _L_GPL implementation of this yet. We have 
> >    nspr under GPL, so we would have to ask to include the asm-snippets
> >    verbatim, even though I'm sure, they would allow using that.
> 
> Aren't they tripple licensing all mozilla code?

Ah, yes, but not yet, and as Havoc aptly pointed out, we wont make it for 2.0,
so we simply wait. I'll add a future bug.

> > So I want to hereby suggest adding:
> >
> > /* not opaque, but prolly in glibconfig.h */
> > typedef struct _GAtomicInt GAtomicInt;
> >
> > /* initialize it, either compile time or run time, just like GStatic*/
> > #define G_ATOMIC_INT_INIT(init_value) ...
> > void g_atomic_int_init (GAtomicInt *atomic_int, gint init_value);
> >
> > /* increment by one; return new value */
> > gint g_atomic_int_inc (GAtomicInt *atomic_int);
> >
> > /* decrement by one; return new value */
> > gint g_atomic_int_dec (GAtomicInt *atomic_int);
> 
> These are a bit more general than what is strictly needed. Are you sure
> the extra generality does not mean problems or inefficiency in the
> implementation for some arch?

No, I'm not sure, but given, that we are havign a function call overhead in
every case, I think oversimplification is not needed. I can very well envision
other needs beside refcounting, hmm, thinking about it, I can't ;-) but that
is oversimplification...

> We really only need
> void atomic_add (GAtomicInt *)
> gboolwan atomic_dec_and_test_if_zero (GAtomicInt *)

I would like to see it more general 
 
> > GAtomicInt of course is just a struct with GStaticMutex and a gint for
> > the fallback case. For the optimized case we of course want it to only
> > be a gint.
> >
> > But as we probably only support the asm-Syntax of gcc, we get a
> > problem: The size of GAtomicInt depends on the compiler used for
> > compiling glib. That means, that a glib compiled by gcc is not binary
> > compatible with a glib compiled by some other compiler for the same
> > platform and programs assuming so will fail in mysterious ways. So
> > _that_ might be a real reason to do it like nspr actually.
> 
> Yes. Having GAtomicInt *only* contain an integer of appropriate size to
> be atomic on the cpu seems like the correct choice.
> 
> > (BTW.: It might seem, that glib already is binary incompatibel
> >  between different compilers on the same platform, but I don't think,
> >  it really is, though I might be wrong)
> 
> I think the headers are source incompatible. If you build it with gcc it
> adds gccisms to glibconfig.h or something.

Yeah, but they are binary compatible, I would claim.

> > So in retrospect I changed my mind ;-) We do i like that: (a mixture
> > between nspr (implementation) and the first idea (interface))
> >
> > typedef volatile gint GAtomicInt;
> 
> The kernel uses
> typedef struct { volatile int counter; } atomic_t;
> 
> I think there was some reason for this. Can't remember right now.

Yes, look better.

I'll file a future bug. Indeed, just now I have an article to write with
deadline Nov 19 and not even an idea, as to what I should write, so I wouldn't
have time anyway.

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi