cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-10065) Introduce AtomicQueue interface
Date Thu, 13 Aug 2015 14:09:45 GMT
Benedict created CASSANDRA-10065:
------------------------------------

             Summary: Introduce AtomicQueue interface
                 Key: CASSANDRA-10065
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10065
             Project: Cassandra
          Issue Type: Improvement
          Components: Core
            Reporter: Benedict
            Assignee: Benedict
            Priority: Minor
             Fix For: 3.x


There have been many occasions where an {{AtomicQueue}} would be helpful in code I've written
to improve clarity and safety, and reviewing some code now I see another such scenario. So
I think it is time to consider (post 3.0) introducing such an interface, and a simple implementation
(one of which can be purloined from my github pretty easily, or we can roll our own)

What does an {{AtomicQueue}} look like? One with CAS like operations for modification, such
as {{pollIfHead(V expect)}}, {{appendIfTail(V expect, V append)}}, {{appendIfEmpty(V append)}},
and iterators with an {{atomicRemove()}} method, which inform you if you were the process
that deleted the element, or if another raced with you and won.

We have lots of duplicate code around which shuffles data from a queue into a volatile variable
to effectively offer this facility. Each one is implemented differently, and generally suboptimally,
so the burden on the project is higher not introducing such a structure.



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

Mime
View raw message