On 11/12/2010 01:29 PM, Mathieu Desnoyers wrote:
* Paolo Bonzini ([email protected]) wrote:
On 11/12/2010 01:19 PM, Mathieu Desnoyers wrote:
* Paolo Bonzini ([email protected]) wrote:
Return nothing can be useful because it can be optimized on x86
as "lock orl (mem), reg/imm". However, there are no other
return-nothing atomic ops in uatomic_*.h so I decided not to
provide this.
How about we start by implementing uatomic_and/uatomic_or that
return void, and if we ever need
uatomic_return_and/uatomic_return_or (see my other mail), we add
them ?
I am using uatomic_or's return value in my call_rcu-with-futex, but
I don't need atomic-or-and-exchange really, I can even change it to
a load followed by an atomic or (it introduces a race but it is
benign).
If the race does not matter, why do we need the new atomic op in the
first place ? ;)
Say the "correct" code would be
atomic x = *p, *p |= FLAG1; # uatomic_xchg_or
if (x & ~FLAG2)
futex_wake (...)
I may try to rewrite it like this:
x = *p; # 1
atomic *p |= FLAG1; # 2, uatomic_or
if (x & ~FLAG2)
futex_wake (...)
This is racy because something can set or reset FLAG2 between 1 and 2.
Setting it may cause spurious wakeups, which are okay. If I know that
nothing can reset FLAG2 between 1 and 2, correctness is preserved.
Instead if I remove atomicity, I get races on read-modify-write
operations, and that is much more obviously incorrect.
But I really do not like being tricky (futexes are tricky enough on
their own), and rather than spending a lot of time proving this correct
I'd probably just use cmpxchg here.
Paolo
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
