Packing 2 data points into 1 field in ThreadPoolExecutor

[David Holmes]

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