linux-mips
[Top] [All Lists]

Re: cmpxchg broken in some situation

To: Thiemo Seufer <ths@networkno.de>
Subject: Re: cmpxchg broken in some situation
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 3 Oct 2007 00:15:48 +0100
Cc: Fuxin Zhang <fxzhang@ict.ac.cn>, linux-mips@linux-mips.org
In-reply-to: <20071002142210.GD16772@networkno.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <46FF7BC2.5050905@ict.ac.cn> <20071001025340.GA7091@linux-mips.org> <47010E15.7060109@ict.ac.cn> <20071001152620.GB15820@linux-mips.org> <470210B4.8020902@ict.ac.cn> <20071002103551.GB5152@linux-mips.org> <20071002142210.GD16772@networkno.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.14 (2007-02-12)
On Tue, Oct 02, 2007 at 03:22:10PM +0100, Thiemo Seufer wrote:

> > +#define __cmpxchg(ptr,old,new,barrier)                                     
> > \
> > +({                                                                 \
> > +   __typeof__(ptr) __ptr = (ptr);                                  \
> > +   __typeof__(*(ptr)) __old = (old);                               \
> > +   __typeof__(*(ptr)) __new = (new);                               \
> > +   __typeof__(*(ptr)) __res = 0;                                   \
> 
> Maybe we need an acquire barrier here for some systems.

Release you meant.  The acquire lock would be at the end.  Documentation
and actual implmeentations of cmpxchg seem to differ.  It's a relativly
rarely used primitve so I think I err on the side of paranoia for now
and throw in the additional SYNC you suggest.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>