From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Fri, 12 Nov 2010 07:38:57 -0500
Subject: [ltt-dev] [PATCH 2/2] introduce uatomic_and and uatomic_or
In-Reply-To: <20101112123018.GB30826@Krystal>
References: <1289552247-18130-1-git-send-email-pbonzini@redhat.com>
	<1289552247-18130-3-git-send-email-pbonzini@redhat.com>
	<20101112120846.GB27929@Krystal> <4CDD2F69.7020407@redhat.com>
	<20101112121900.GA29642@Krystal> <4CDD31E7.1050500@redhat.com>
	<4CDD32AC.2050308@redhat.com> <20101112123018.GB30826@Krystal>
Message-ID: <20101112123856.GA31489@Krystal>

* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> * Paolo Bonzini (pbonzini at redhat.com) wrote:
> > On 11/12/2010 01:24 PM, Paolo Bonzini wrote:
> >> Should I rename uatomic_add to uatomic_xchg_add too (I prefer this name
> >> to uatomic_return_add)?
> >
> > Uh, uatomic_add returns void actually.  Then returning void from  
> > uatomic_{and,or} is indeed more consistent.
> 
> Ah! I knew we'd find the culprit!! ;-)

BTW, I'd be fine with adding:

uatomic_and/uatomic_or (returning void)

But I wonder if, on any architecture, there is a significantly better
way to implement:

uatomic_xchg_add/uatomic_xchg_or (returning the old value)

other than using a cmpxchg() underneath ? If not, then creating this
extra primitive would be pretty much useless.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com