[jira] [Created] (CASSANDRA-10065) Introduce AtomicQueue interface

["Benedict (JIRA)" <ji...@apache.org>]

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)