Re: SMP barriers missing?

On 1/6/06, Amit Kale <amitkale@xxxxxxxxxxxxxx> wrote:
> atomic_read, atomic_set and atomic_inc are defined in a way that ensures that
> the value being read, written or updated is always consistent and correct
> across all processors. If these macros don't include a memory barrier on some
> platform, that would be because that platform doesn't need it.

I tried to find out more about this; I think what you say here isn't
so, unfortunately.  I bugged David Miller (author of atomic_ops.txt)
about this for clarification, and he confirmed that atomic_set is
intended to have no special barrier/cache-sync/miscellaneous magic
semantics at all.  It's just an assignment.

On the SPARC and PA-RISC, you will see the atomic op implementations
taking spinlocks while they do the set, but that's necessary because
those machines have no atomic read-modify-write operations at all. 
The only way to get (say) atomic_add and atomic_set to interoperate
properly is to hold a spinlock; otherwise, you can get results that
are inconsistent with any possible ordering of an atomic assignment
and an atomic add.  That implementation just happens to enforce a
global ordering on the operations, but that's unnecessary.  However,
there's no need for synchronization in the atomic_read operation,
since all those operations only do one store.

Using atomic_set, alone, doesn't guarantee that other processors will
ever see the assignment.  If you do two atomic_sets on one processor,
there's no guarantee that other processors will see those assignments
in the order they were executed (or see them at all).  You need to use
explicit barriers, or atomic operations that return values (which are
required to have barrier semantics, according to atomic_ops.txt).

I don't have any SMP machines handy at all, let alone one that is
loose with its memory operation ordering.  So I can't contribute much
to this in a concrete way.  But in general, the KGDB
exception-handling code is not performance-critical, and it is not
very accessible for debugging, so I would think it would make sense to
err on the side of obvious correctness and include explicit barriers
whereever it seems they might make a difference.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642