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

["C. Scott Andreas (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

C. Scott Andreas updated CASSANDRA-10065:
-----------------------------------------
    Component/s: Core

> Introduce AtomicQueue interface
> -------------------------------
>
>                 Key: CASSANDRA-10065
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10065
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Priority: Minor
>             Fix For: 4.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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org