On 2/12/2014 4:51 PM, Alex Yursha wrote:
Thanks for all responses. All this is much clearer now.
Am I right that all this state packing is for better performance only and the
same behaviour can be achieved by using explicit locks?
Sure.
David
On Dec 2, 2014, at 05:32, David Holmes
Thanks for all responses. All this is much clearer now.
Am I right that all this state packing is for better performance only and the
same behaviour can be achieved by using explicit locks?
On Dec 2, 2014, at 05:32, David Holmes david.hol...@oracle.com wrote:
On 2/12/2014 3:44 AM, Alex
It allows to manipulate two (related) bits of info atomically without
needing a lock and when efficient double CAS is not available (which it
isn't on supported archs).
Sent from my phone
On Dec 1, 2014 12:23 PM, Alex Yursha alexyur...@gmail.com wrote:
Hi all,
According to javadoc current
The only way to use atomic compare and set is to pack all your state
into a single primitive unit. The largest we have is long. So we
regularly pack what the C folks would call bitfields into longs.
On Sat, Nov 29, 2014 at 8:13 AM, Alex Yursha alexyur...@gmail.com wrote:
Hi all,
According to
Thanks a lot.
Seems like i need to look deeper into the JVM and hardware intrinsics to
understand some pecularities of core libs class designs.
Sent from my iPhone
On Dec 1, 2014, at 20:27, Vitaly Davidovich vita...@gmail.com wrote:
It allows to manipulate two (related) bits of info
1. Do you mean 'the only way', except using a lock?
2. I also cant imagine how we can use long primitive type for CAS atomicity
without a lock if only its not an AtomicLong. Any hint here, please?
Thanks
Sent from my iPhone
On Dec 1, 2014, at 20:27, Martin Buchholz marti...@google.com
On 2/12/2014 3:44 AM, Alex Yursha wrote:
1. Do you mean 'the only way', except using a lock?
2. I also cant imagine how we can use long primitive type for CAS atomicity
without a lock if only its not an AtomicLong. Any hint here, please?
AtomicFieldUpdater can apply atomic operations to
