[ 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org