[
https://issues.apache.org/jira/browse/CASSANDRA-11517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230056#comment-15230056
]
Sylvain Lebresne commented on CASSANDRA-11517:
----------------------------------------------
I'm all for that change in principle, but the attached branch doesn't work. The
CAS loop properly sets the {{lastNanos}} but return {{nanosSince}}, which stays
the same for a whole seconds (this breaks tons of unit test in particular). The
added unit test (which fails consistently) also looks weird: the
{{lastTimestamp}} used by the tasks is never updated and the condition {{if
(lastTimestamp <= uuid.timestamp())}} seems to be the invert of what we want.
Nit: call me crazy but the asymmetry of {{lastNanosOriginal}} and
{{newLastNanos}} pains me (that is, I'd use {{originalLastNanos}} instead).
Lastly, as much as doing this make sense, I think this belong to trunk only (as
a minor improvement).
> o.a.c.utils.UUIDGen could handle contention better
> --------------------------------------------------
>
> Key: CASSANDRA-11517
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11517
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Ariel Weisberg
> Assignee: Ariel Weisberg
> Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> I noticed this profiling a query handler implementation that uses UUIDGen to
> get handles to track queries for logging purposes.
> Under contention threads are being unscheduled instead of spinning until the
> lock is available. I would have expected intrinsic locks to be able to adapt
> to this based on profiling information.
> Either way it's seems pretty straightforward to rewrite this to use a CAS
> loop and test that it generally produces unique values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
