On Thu, 30 Mar 2006, Nick Piggin wrote:
> Zoltan Menyhart wrote:
>
> > However, I do not think your implementation would be efficient due to
> > selecting the ordering mode at run time:
> >
> > > + switch (mode) {
> > > + case MODE_NONE :
> > > + case MODE_ACQUIRE :
> > > + return cmpxchg_acq(m, old, new);
> > > + case MODE_FENCE :
> > > + smp_mb();
> > > + /* Fall through */
> > > + case MODE_RELEASE :
> > > + return cmpxchg_rel(m, old, new);
> >
>
> BTW. Isn't MODE_FENCE wrong? Seems like a read or write could be moved
> above cmpxchg_rel?
Hmmm.... We should call this MODE_BARRIER I guess...
> I think you need rel+acq rather than acq+rel (if I'm right, then the
> same goes for your earlier bitops patches, btw).
The question is what does fence imply for the order of the atomic
operation. Will the operation be performed before or after the barrier?
Or do we need barriers on both sides?
If so then we may simulate that with a release and then do a acquire load
afterwards
cmpxchg_rel(m, old, new);
return *m; /* m volatile so it has acquire semantics */
-
: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|