cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8963) Make OpOrder more intuitive
Date Thu, 16 Jul 2015 16:05:05 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629934#comment-14629934
] 

Benedict commented on CASSANDRA-8963:
-------------------------------------

I would say leave this until I've actually posted a patch for review, but if there's even
the hint that there may be review problems, Sylvain is probably right on another count: this
should wait until after 3.0

To respond to that specific one: however you feel about bit-fiddling, that particular issue
of "readability" can be trivially solved by a static method or two to make it declarative,
which is now my norm for such encodings. However the _conceptual_ clarity delivered by separating
the count from the "is finished" flag is IMO more than a compelling enough reason to change.

If that snippet were, for instance, written as:

{code}
int current = state;
int next = runningCount(current) - 1;
next |= finishingFlag(current);
{code}

I think it makes it quite significantly clearer, especially as we now have only one location
to worry about concurrent interactions (a single CAS), and no thinking through what the count
means when it is < 0 by comparison to what it means when > 0. There is simply a count
portion, and a flag portion, and they are truly orthogonal.

> Make OpOrder more intuitive
> ---------------------------
>
>                 Key: CASSANDRA-8963
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8963
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>             Fix For: 3.x
>
>
> There has been plenty of feedback about OpOrder being unintuitive. As well as revisiting
the naming, I propose to introduce an Action object with RAII (AutoCloseable) protection that
should be more obvious to users of the API. We can also then protect this by a Ref instance
for use cases where the action lifetime is illdefined, and perhaps also introduce some checks
for actions whose lifetimes extend beyond a sensible limit to report those where the object
reference is retained.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message