[Bug translator/6932] c->busy can be non-atomic.

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From jistone at redhat dot com  2009-03-03 20:02 -------
My apologies if I'm over-thinking this, but I really do think we have a subtle
bug here...

(In reply to comment #16)
> For the "busy" flag, I don't think ordering issues arise if we continue to
> use the atomic.h API.  Concurrent reads/writes are SMP-synchronized - that's 
> the whole point.

Yes, but only regarding that particular variable.  It says nothing about the
ordering wrt neighboring reads/writes.

> Note that we only write c->fields if the atomic_inc_return
> returned the proper value.

Ah, ok, atomic_ops.txt does document that atomic operations which return a value
will act as a full memory barrier both before and after.  The atomic_dec()s may
still be an issue though, which we could fix either by making them
atomic_dec_return(), or inserting an smp_mb__before_atomic_dec().

(In reply to comment #17)
> Sure, I agreed. I hope someone who has bigger SMP machine tests this patch 
> and find meaningful results.

Unfortunately, I don't have any such machines.  But anyway, you could also
consider using local_t, which keeps the same barrier semantics as atomic_t
without the cross-CPU bus locks.

> BTW, I think we can check busy flags safely with smp_call_function.

It may be safe, but why would you want to do this?  I see no advantage over the
simple loop that we have now...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=6932

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.