atomic_cmpxchg and 64-bit values

atomic_cmpxchg and 64-bit values

[Brent Casavant]

Hello,

I have what I hope is an easy to answer question.

The IA64 atomic_cmpxchg macro reads as follows (line continuation inserted):

	#define atomic_cmpxchg(v, old, new) \
		((int)cmpxchg(&((v)->counter), old, new))

Note that there's an integer cast on the return from cmpxchg().
This seems strange considering that the entire compxchg() code
path takes care to make sure that correctly-sized data types are
used throughout, including the return path.  The atomic_xchg()
macro

Is there some particular reason we need the cast to int on the
return path for atomic_cmpxchg()?  It looks to me as if this
macro would work equally well with an atomic_t or an atomic64_t.

Thanks,
Brent

-- 
Brent Casavant                          All music is folk music.  I ain't
bcasavan@sgi.com                        never heard a horse sing a song.
Silicon Graphics, Inc.                    -- Louis Armstrong

Re: atomic_cmpxchg and 64-bit values

[Andreas Schwab]

Brent Casavant <bcasavan@sgi.com> writes:

> Is there some particular reason we need the cast to int on the
> return path for atomic_cmpxchg()?  It looks to me as if this
> macro would work equally well with an atomic_t or an atomic64_t.

No, this is won't work, atomic_cmpxchg is strictly only defined for
atomic_t.  See commit 4a6dae6d382e9edf3ff440b819e554ed706359bc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: atomic_cmpxchg and 64-bit values

[Christoph Lameter]

On Wed, 17 Jan 2007, Andreas Schwab wrote:

> Brent Casavant <bcasavan@sgi.com> writes:
> 
> > Is there some particular reason we need the cast to int on the
> > return path for atomic_cmpxchg()?  It looks to me as if this
> > macro would work equally well with an atomic_t or an atomic64_t.
> 
> No, this is won't work, atomic_cmpxchg is strictly only defined for
> atomic_t.  See commit 4a6dae6d382e9edf3ff440b819e554ed706359bc.

Use cmpxchg instead of atomic_cmpxchg.

Re: atomic_cmpxchg and 64-bit values

[Brent Casavant]

On Thu, 18 Jan 2007, Christoph Lameter wrote:

> On Wed, 17 Jan 2007, Andreas Schwab wrote:
> 
> > Brent Casavant <bcasavan@sgi.com> writes:
> > 
> > > Is there some particular reason we need the cast to int on the
> > > return path for atomic_cmpxchg()?  It looks to me as if this
> > > macro would work equally well with an atomic_t or an atomic64_t.
> > 
> > No, this is won't work, atomic_cmpxchg is strictly only defined for
> > atomic_t.  See commit 4a6dae6d382e9edf3ff440b819e554ed706359bc.
> 
> Use cmpxchg instead of atomic_cmpxchg.

There was a better solution anyway.  I was trying to stash a pointer
in the atomic as an ownership token, and that of course was fraught with
peril as you need an atomic_t or atomic64_t, depending on platform.

In the end I decided to use a non-pointer unique token rather than
deal with the 32/64-bit hassle, which also sidestepped the whole
question about the (int) cast.

Thanks you both for the responses though.

Brent

-- 
Brent Casavant                          All music is folk music.  I ain't
bcasavan@sgi.com                        never heard a horse sing a song.
Silicon Graphics, Inc.                    -- Louis Armstrong