You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Thomas Koch (JIRA)" <ji...@apache.org> on 2010/12/07 11:42:09 UTC
[jira] Created: (ZOOKEEPER-955) Use Atomic(Integer|Long) for (Z)Xid
Use Atomic(Integer|Long) for (Z)Xid
-----------------------------------
Key: ZOOKEEPER-955
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
Project: ZooKeeper
Issue Type: Improvement
Components: java client, server
Reporter: Thomas Koch
Assignee: Thomas Koch
Priority: Trivial
As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
[1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Henry Robinson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968875#action_12968875 ]
Henry Robinson commented on ZOOKEEPER-955:
------------------------------------------
Hi Thomas -
Nice thought - definitely worth checking out. Please do benchmark this, however - it is not completely clear cut which is the better synchronization primitive.
Atomic* objects usually call into a system-specific compare and swap method, usually (on x86) a CMPXCHG instruction which locks the bus whether or not the compare is successful. This is probably the same hardware synchronization primitive that Java's thin locks use.
Java locks are usually some form of thin locks, at least in HotSpot [1], which are locks that are fast in the uncontended case - they are just as fast as CAS on words. In the contended case, the lock is inflated which is a one-time spinning step, after which it is a OS-based mutex which we would expect to be slower than Atomic primitives in general. However, when lock contention is very high, you might find that synchronized blocks perform better as optimistic locking implies a busy wait loop when a lock can't be taken.
Henry
[1] http://wikis.sun.com/display/HotSpotInternals/Synchronization
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-955) Use Atomic(Integer|Long) for (Z)Xid
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-955:
------------------------------------
cancelling the patch, since we arent clear if we need it...
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969174#action_12969174 ]
Mahadev konar commented on ZOOKEEPER-955:
-----------------------------------------
ben/henry, any one of you can volunteer for running some benchmarks?
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Thomas Koch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969365#action_12969365 ]
Thomas Koch commented on ZOOKEEPER-955:
---------------------------------------
I'm myself +0 on this patch after what I've learned about synchronization now. It was just a WTF moment when I saw this code and asked myself why the author didn't use Atomic classes from the beginning. The comment you mentioned ("This should be called from a synchronized block on this!") is obsolete, I believe since the function is already synchronized.
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-955) Use Atomic(Integer|Long) for (Z)Xid
Posted by "Thomas Koch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Koch updated ZOOKEEPER-955:
----------------------------------
Attachment: ZOOKEEPER-955.patch
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] [Updated] (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-955:
------------------------------------
Fix Version/s: (was: 3.4.0)
3.5.0
not a blocker. Moving it out of 3.4 release.
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Thomas Koch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968973#action_12968973 ]
Thomas Koch commented on ZOOKEEPER-955:
---------------------------------------
Unfortunately I don't have access to a cluster or even one big dedicated machine to run benchmarks that would make any sense. And frankly I'm afraid of stress testing ZooKeeper on my laptop, which would also mean stress testing my 3 years old hard disc...
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968684#action_12968684 ]
Hadoop QA commented on ZOOKEEPER-955:
-------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12465683/ZOOKEEPER-955.patch
against trunk revision 1040752.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
-1 findbugs. The patch appears to introduce 8 new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/63//testReport/
Findbugs warnings: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/63//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/63//console
This message is automatically generated.
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968903#action_12968903 ]
Mahadev konar commented on ZOOKEEPER-955:
-----------------------------------------
nice explanation henry! never knew about this!
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Henry Robinson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969363#action_12969363 ]
Henry Robinson commented on ZOOKEEPER-955:
------------------------------------------
Based on a very quick look at the code, I'd be surprised if this were a bottleneck. There are roughly two important call sites for these methods: one is in the PrepRequestProcessor and one is in the ResponderThread during responses to leader requests. I don't think there's a reasonable benchmark that would show any difference between the two threads based on their behaviour alone.
The question, then, is whether synchronizing on the ZooKeeperServer is fine-grained enough as other methods are taking the 'this' lock on instances of ZKS. Moving to AtomicLong would begin to partition the locking strategy for ZKS, and since AtomicLong can't be used in a thread-unsafe way there's none of the normal concerns with fine-grained locking about making the locking strategy more complex and therefore error-prone. However in general we should be very cautious about re-partitioning locks; this can cause all sorts of pain. We should certainly understand the contention profiles for certain locks before coming up with a strategy.
Given that, I'm +0 on this patch. I'm not sure it really solves a significant problem, but it has the potential to ease synchronization costs, and doesn't cost much in terms of resources. It would also fix the problem in my version of trunk where getZxid is synchronized, but has this comment: "This should be called from a synchronized block on this!" ...
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-955) Use Atomic(Integer|Long) for (Z)Xid
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-955:
------------------------------------
Hadoop Flags: [Reviewed]
+1 looks good. have you benchmarked to make sure that it improved performance? (or at least didn't make it worse :)
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-955) Use Atomic(Integer|Long) for
(Z)Xid
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969399#action_12969399 ]
Benjamin Reed commented on ZOOKEEPER-955:
-----------------------------------------
following up on henry's comment, it appears that we are indeed calling some of these from synchronized blocks, but they are really only synchronized for the call itself. we should remove those as well since it would be confusing to mix synchronization and AtomicX. it would also allow us to make sure there isn't a side effect of the synchronization that we are missing.
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-955) Use Atomic(Integer|Long) for (Z)Xid
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-955:
------------------------------------
Fix Version/s: 3.4.0
marking it for 3.4 if someone can run some performance numbers with this, we can include it in 3.4 release.
> Use Atomic(Integer|Long) for (Z)Xid
> -----------------------------------
>
> Key: ZOOKEEPER-955
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-955
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client, server
> Reporter: Thomas Koch
> Assignee: Thomas Koch
> Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-955.patch
>
>
> As I've read last weekend in the fantastic book "Clean Code", it'd be much faster to use AtomicInteger or AtomicLong instead of synchronization blocks around each access to an int or long.
> The key difference is, that a synchronization block will in any case acquire and release a lock. The atomic classes use "optimistic locking", a CPU operation that only changes a value if it still has not changed since the last read.
> In most cases the value has not changed since the last visit so the operation is just as fast as a normal operation. If it had changed, then we read again and try to change again.
> [1] Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.