Re: public barrier functions

[Balazs Scheidler <bazsi balabit hu>]

On Mon, 2005-12-12 at 22:41 +0100, Sebastian Wilhelmi wrote:
> Hi Balazs,
> 
> > Is there a specific reasons why the barrier functions implemented by
> > gatomic.c and gatomic.h are not exported APIs?
> 
> We didn't want to create the Swiss army knife for high performance
> multithread programming, just atomic integers. As you are surely aware,
> using memory barriers is far from an easy topic and bugs are easily
> introduced.

Sure. I only wanted to avoid using locks on the fastpath of my
application, but I already solved it with atomic integers and I've read
a lot of articles on memory barriers in the meanwhile.


> > And while I am at it, would it be possible to change the atomic
> > operations to inline functions? I'd think it is much better inline
> > single-instruction functions as otherwise the call overhead is too
> > great.
> 
> That would make it impossible to fix the corresponding implementations
> also for already compiled programs, should bugs surface (which they
> already did) and it would also make it impossible to guarantee, that all
> programs really use the same implementation, i.e. with inline functions
> one module could use the asm version (because gcc is used) and the
> second module would use the mutex versions (because another compiler is
> used). That would be very bad of course.

That's a valid point but maybe it would be possible to request inlined
implementations of some functions by the use of a preprocessor symbol,
e.g.

#define G_GLIB_USE_INLINE_FUNCS
#include <glib.h>

Of course this would only be possible if it is not a maintenance
head-ache, e.g. the copied function bodies should not be copied, but
autogenerated instead.

Would something like this be accepted?

-- 
Bazsi