On 06/13/2010 11:28 PM, Paul E. McKenney wrote:
On Sun, Jun 13, 2010 at 05:20:34PM -0400, Mathieu Desnoyers wrote:
* Paul E. McKenney ([email protected]) wrote:
On Thu, Jun 10, 2010 at 09:46:31PM -0400, Mathieu Desnoyers wrote:
[...]
(will reply to the rest in the individual patches)
Can we trust __sync_lock_test_and_set/__sync_add_and_fetch given that
__sync_synchronize is broken ?
I don't know yet. If it turns out that we cannot, then I will use some
form of global locking. But the __sync_lock_test_and_set() do at least
generate instructions, unlike __sync_synchronize(). ;-)
I'm concerned about the fact that their synchronization primitives might have
the assembly all with, except for the memory barriers.
The default implementation of these __sync_* builtins is based on
cmpxchg, and will cause a link error unless cmpxchg is also available
(either in libgcc or with a compiler-provided inline implementation).
Instead, the default implementation of __sync_synchronize is to just do
a compiler barrier. ARM implements __sync_synchronize only for Linux,
so at least there it is not needed. Strange that Paul needs it too.
Anyway, a simple configure test is to compile this with -fdump-rtl-expand:
int
f()
{
__sync_synchronize();
}
If the assembly output includes "__sync_synchronize", or the dump file
includes the text "unspec:BLK", it should be fine. In particular, ia64,
mips, and Alpha are ok. Else you can use the pthreads trick. I can try
to make a patch if you're interested. Or, more simply, it's possible to
hardcode the above three platforms since it's unlikely that others will
be added soon.
Paolo
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
