Re: SMP barriers missing?

Jim,

I fully agree that regardless of whether the possibility of kgdb variables 
going out of syn is near impossible, we should fix it if we can establish 
that it exists.

I generally find the description below correct, though I can't understand how 
any kgdb variable will go out of sync because of that. Consider the following 
code

atomic_t gv;

void incit(void)
{
  atomic_inc(&gv);
}


I would think that regardless of in what sequence incit is called on different 
processors, the value of gv at the end of all the execution should be equal 
to to the number of calls to incit.

The same code written in a slightly different way as given below should also 
show the same results

spinlock_t slk = SPIN_LOCK_UNLOCKED;
volatile int gv;
void incit(void)
{
 spinlock_lock(&slk);
 gv++;
 spinlock_unlock(&slk);
}


-Amit

On Thursday 26 Jan 2006 5:08 am, Jim Blandy wrote:
> 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
> _______________________________________________
> Kgdb-bugreport mailing list
> Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport


-------------------------------------------------------
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&kid=103432&bid=230486&dat=121642