[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544300#comment-17544300
]
Benedict Elliott Smith commented on CASSANDRA-16681:
----------------------------------------------------
bq. E.g. this structure has a counter of non-null fields. When either adding or
removing it updates the fields and updates the counter. How do you ensure the
other threads see a consistent state? Not sure, but I'm afraid at least some
CAS would be needed somewhere.
I was proposing removing the count entirely, as it is a minor optimisation.
Simply use the three fields and their null/non-null status. The owning thread
is only permitted to set to non-null (and assures safe publication), and the
other threads may only set to null, and may either only do so if they have
taken ownership of the act, by first transitioning -1 -> 0, or perhaps would do
so using CAS (whereas the owning thread could perhaps do so with e.g.
{{putOrdered}} )
This at least is a very narrow piece of code to analyse, which is probably
safer than modifying the `BufferPool` which appears to have grown too complex
since it was first introduced. Some time in future, we should consider
refactoring more fully, to perhaps distinguish the `LocalPool` and `TinyPool`
concepts more fully so that we do not make this kind of mistake, as the
behaviour is subtly different between the two, and it is easy to forget this
and fail to account for the special-casing.
Still, you have indicated that this wouldn't materially simplify the patch
(indeed, it sounds like it would make it more complicated), so I agree that's a
waste of time.
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
> Reporter: Ekaterina Dimitrova
> Assignee: Piotr Kolaczkowski
> Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Attachments: 0001-Fix-memoryInUse-counter-in-BufferPool.patch,
> 0002-Multiple-fixes-in-BufferPool-and-LongBufferPoolTest.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]