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 <david.hol...@oracle.com> wrote:
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 plain (volatile) int and long
fields. The Unsafe API can also be used to do it more performantly.
David
Thanks
Sent from my iPhone
On Dec 1, 2014, at 20:27, Martin Buchholz <marti...@google.com> wrote:
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 javadoc current implementation of ThreadPoolExecutor packs two
conceptual fields ‘workerCount’ and ‘runState’ into one actual field ‘ctl’ of
type AtomicInteger.
Could you please explain are there any performance or other benefits for this?
It seems to complicate the class design and I can’t find the positive side of
this.
Thanks,
Alex
