[concurrency-interest] Atomic get/set vs compareAndSet

David Holmes davidcholmes at aapt.net.au
Fri Apr 30 18:01:38 EDT 2010


Peter,

> > My question is if the get/set combination causes less contention on
> > the memory bus compared to a cas. So it is a common practice to
> > replace cas by get/sets if possible?

The answer to the second part is a qualified yes. In terms of locking
schemes if you need a CAS to acquire and a CAS to release then it's a 1/1
scheme. A common goal is to have a scheme that supports 1/0 locking ie no
CAS on unlock only a simple store (plus any needed fences). Your example is
slightly different in that you have to read the lockowner field, which means
you need a load+store.

But to answer in terms of contention on the bus ... well that depends on a
lot of detail. You are using atomic operations which imply volatile
semantics (I assume) so there may be extra fences involved with the get/set
combination compared to the CAS - and the fences might hurt you more than
the CAS would. But it really depends on the exact machine code that will
execute and on the exact system you are on. This is way too low a level of
detail for me to discuss. I'd recommend checking Dave Dice's blogs:

http://blogs.sun.com/dave/

as they cover a lot of things in this area.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> Veentjer
> Sent: Saturday, 1 May 2010 1:52 AM
> To: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Atomic get/set vs compareAndSet
>
>
> I made a copy paste error in the example I see. This is the good code.
>
> public void ___releaseLock(Transaction expectedLockOwner) {
>  ___LOCKOWNER_UPDATER.compareAndSet(this, expectedLockOwner, null);
> }
>
> example of a get/set
>
> public void ___releaseLock(Transaction expectedLockOwner) {
> if (___LOCKOWNER_UPDATER.get(this) == expectedLockOwner) {
>      ___LOCKOWNER_UPDATER.set(this, null);
> }
> }
>
>
> On Fri, Apr 30, 2010 at 5:49 PM, Peter Veentjer
> <alarmnummer at gmail.com> wrote:
> > I have a question about the contention costs on the memory bus of a
> > cas vs a get/set pair.
> >
> > e.g. an example of a cas.
> >
> >  @Override
> >    public void ___releaseLock(Transaction expectedLockOwner) {
> >        ___LOCKOWNER_UPDATER.compareAndSet(this, null,
> > expectedLockOwner, set(this, null);
> >    }
> >
> >
> > example of a get/set
> >
> >  @Override
> >    public void ___releaseLock(Transaction expectedLockOwner) {
> >        if (___LOCKOWNER_UPDATER.get(this) == expectedLockOwner) {
> >            ___LOCKOWNER_UPDATER.set(this, null);
> >        }
> >    }
> >
> > From a logical point of view both provide the same semantics. In case
> > of the get/set it can't
> > happen that another thread changes the lock owner after it has been
> > locked. So I don't
> > need to worry about another thread updating the lock owner after the
> > get has returned
> > the expectedLockOwner (get/set essentially have become atomic).
> >
> > My question is if the get/set combination causes less contention on
> > the memory bus
> > compared to a cas. So it is a common practice to replace cas by
> > get/sets if possible?
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest




More information about the Concurrency-interest mailing list