Packing 2 data points into 1 field in ThreadPoolExecutor

[Alex Yursha]

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.holmes at 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 <martinrb at 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 <alexyursha at 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
>>>>