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