[
https://issues.apache.org/jira/browse/HBASE-12148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160034#comment-14160034
]
Lars Hofhansl commented on HBASE-12148:
---------------------------------------
Is this correct:
{code}
+ long minimumTimestamp = INITIAL_MINIMUM_TIMESTAMP;
...
+ if (timestamp < this.minimumTimestamp) {
+ synchronized (this) {
+ if (!init(timestamp)) {
...
+ } else if (timestamp > this.maximumTimestamp) {
+ synchronized (this) {
+ if (!init(timestamp)) {
...
{code}
?
{{this.minimumTimestamp}} might be in flight of being changed.
Your reasoning is that minimumTimestamp will only get smaller and
maximumTimestamp only bigger... Hence the check here will not actually miss a
change? (i.e. if the new value is not smaller than the current minTS it is
definitely not smaller than any new version of minTS...?)
That might work, but it's risky. On 32bit systems an update to long is not
atomic in Java, so a reader here might see a partially updated long.
I think you cannot get around declaring minimumTimestamp and maximumTimestamp
volatile, that will add some of the overhead back in.
[~stack], [~apurtell].
> Remove TimeRangeTracker as point of contention when many threads writing a
> Store
> --------------------------------------------------------------------------------
>
> Key: HBASE-12148
> URL: https://issues.apache.org/jira/browse/HBASE-12148
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Affects Versions: 2.0.0, 0.99.1
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0, 0.98.7, 0.99.1
>
> Attachments: 12148.txt, 12148.txt, 12148v2.txt, 12148v2.txt, Screen
> Shot 2014-10-01 at 3.39.46 PM.png, Screen Shot 2014-10-01 at 3.41.07 PM.png
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
