[
https://issues.apache.org/jira/browse/CASSANDRA-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-10065:
---------------------------------
Assignee: (was: Benedict)
> 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: 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)
