[concurrency-interest] Atomic get/set vs compareAndSet

Peter Veentjer alarmnummer at gmail.com
Fri Apr 30 11:52:25 EDT 2010


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?
>



More information about the Concurrency-interest mailing list