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 wrote:
>
> On 2/12/2014 3:44 AM, Alex Yursha wrote:
>> 1. Do yo
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 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
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 wrote:
>
> The only wa
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 wrote:
>
> It allows to manipulate two (related) bits of info atomically without ne
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 wrote:
> Hi all,
>
> According to javadoc current
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" wrote:
> Hi all,
>
> According to javadoc current implementation of T
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
