Re: public barrier functions

[Sebastian Wilhelmi <seppi seppi de>]

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.

> I'd like to avoid locking in some situations where these memory barrier
> instructions would come handy.
> 
> One thread:
>   ptr = NULL
> 
> Other thread:
>   void *my_ptr = ptr;
> 
>   if (ptr)
>     {
>     }
> 
> Of course this would be a race condition if I was trying to use the
> pointer, but if I add reference counting like this:
> 
> One thread:
>   loc_ptr = ptr;
>   ptr = NULL;
>   g_data_unref(loc_ptr);
> 
> Other thread:
>   void *my_ptr = g_data_ref(ptr);
> 
>   if (my_ptr)
>     {
>     }
> 
> Unless I miss something this should work, provided:
>   1) provided g_data_ref handles NULL pointers
>   2) the reference count of ptr itself is manipilated with atomic
> operations.
>   3) the CPU ensures proper read/write memory ordering
> 
> Now this is not true on some non-x86 CPUs in which case I'd need
> something like:
> 
> One thread:
>   loc_ptr = ptr;
>   ptr = NULL;
>   wmb();
>   g_data_unref(loc_ptr);
> 
> Other thread:
>   void *my_ptr = g_data_ref(ptr);
> 
>   if (my_ptr)
>     {
>     }
> 
> Now the question is why the memory barrier macros are hidden in the
> gatomic module and not exported.

Actually I'm not quite sure, what you want to achieve here. Can you
elaborate? However for transferring pointers from one thread to another
you can use g_atomic_pointer_compare_and_exchange for writing and
g_atomic_pointer_get for reading and be ready.

> 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.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                 |            här ovanför alla molnen
mailto:seppi seppi de              |      är himlen så förunderligt blå
http://seppi.de