Re: Fix unlock_buffer() to work the same way as bit_unlock()

[Christoph Lameter <clameter@sgi.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/