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 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
