Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26444

Re: java.util.concurrent.atomic

Show all headers | View raw

On 27.10.13 02.25, markspace wrote:
> AtomicReference
>
> Here's something I forget about: update an object reference atomically.
> I'm having trouble thinking of a good use case for this class however.
> Does anyone have an interesting example of its use?

Almost any Lock-Free algorithm relies on atomic references.

A classical is a lock free locator with many parallel readers and only a 
few writes. The trick is to use immutable and therefore intrinsically 
thread-safe objects.
You can make this locator thread-safe with an atomic reference to a 
Hashtable. Once a Hastable instance is exposed to the other threads by 
this atomic reference it must not be modified any more. So all read 
operations are safe. If the Hashtable is to be modified, it is copied, 
modified and then the atomic reference is switched to the new revision. 
Concurrent writers can be synchronized by a CAS loop or simply by a 
synchronized block.
The only thing you have to care about is that the atomic reference does 
not provide repeatable read semantics, of course. But you can easily 
take a snapshot of the current content by simply taking a local reference.

> AtomicIntegerArray
> AtomicLongArray
> AtomicReferenceArray
>
> Holy cow! Remember when we get questions about "can I make array
> elements with volatile memory semantics"? I recall us answering "no" to
> that question.

You cannot access the entire array atomically, but surely you can access 
/single/ integers in the array atomically. AtomicInteger[] would do the 
job as well, but it might be unwanted because of the many allocations 
for each AtomicInteger object. However, AtomicIntegerArray is likely to 
cause ->false sharing, which can be orders of magnitude slower than the 
additional allocations of AtomicInterger[]. So handle with care.

> AtomicIntegerFieldUpdateder
> AtomicLongFieldUpdater
> AtomicReferenceFieldUpdater
>
> These are hella cool. They update fields within a class atomically. Yet
> I'm having trouble thinking of uses cases for these as well. Any ideas?

These classes give you the option to access a field with memory barrier 
only on demand. An Implementation of the double check idiom might use this.
But, since Java does not support references to built-in value types, 
they cannot be used without reflection. So I would recommend not to use 
them. Instead make the field volatile or use AtomicXXX and avoid any 
unnecessary unsynchronized access to the field by using local copies. 
Most of the time this is faster with respect to cache efficiency too.

> AtomicReferenceFieldUpdater has an worked out code example involving a

Same applies to this one.

> AtomicMarkableReference
> AtomicStampedRefernce
 >
> Ditto with these two classes. They seem cool, but I'm not sure what I'd
> use them for.

I never needed something like that. AFAIK it can be used to implement 
some lock-free algorithms like linked lists and skip lists.
The basic idea is to update /two/ fields atomically. The implementations 
expose the special case of tuples of <T,bool> and <T,int>.

Some hardware platforms have built-in CPU instructions for this purpose 
(atomically access two machine size words). But since the implementation 
does not use this, I see no significant benefit of using this classes.


> Additional comments and insights on these classes are appreciated!

I often deal with atomic operations and lock free algorithms. The can be 
extremely fast and scalable. But developing lock free algorithms is also 
art.
Most of the time I use C++ and .NET, but since this is very close to the 
hardware there are only minor language dependencies.
The next interesting point will be transactional memory.


Marcel

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

java.util.concurrent.atomic markspace <markspace@nospam.nospam> - 2013-10-26 17:25 -0700
  Re: java.util.concurrent.atomic Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-10-26 19:56 -0700
    Re: java.util.concurrent.atomic Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-29 20:35 +0000
      Re: java.util.concurrent.atomic Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-10-29 17:27 -0400
      Re: java.util.concurrent.atomic Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-10-29 22:36 +0100
      Re: java.util.concurrent.atomic Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-10-29 21:17 -0700
  Re: java.util.concurrent.atomic Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-10-27 10:09 +0100

csiph-web