[
https://issues.apache.org/jira/browse/CASSANDRA-21160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18057334#comment-18057334
]
Arvind Kandpal commented on CASSANDRA-21160:
--------------------------------------------
Hi,
I have looked into the code for {{{}VectorMemoryIndex{}}}, and here is what I
found:
The {{add}} method is currently {{{}synchronized{}}}, which serializes the
entire insertion process. As the description suggests, this creates unnecessary
contention since the underlying graph structure supports concurrent writes.
*My thought process on the fix:* Simply removing the {{synchronized}} keyword
isn't enough because {{updateKeyBounds}} modifies the mutable {{minimumKey}}
and {{{}maximumKey{}}}. If we remove the lock entirely, updates to these bounds
won't be thread-safe.
*Proposal:* I plan to remove {{synchronized}} from the {{add}} method signature
but wrap the {{updateKeyBounds(primaryKey)}} call in a {{synchronized}} block.
This ensures that the heavy {{graph.add}} operation runs concurrently, while
the lightweight bounds update remains protected.
Is this correct approach ?
> VectorMemoryIndex has unnecessary synchronization on the add method
> -------------------------------------------------------------------
>
> Key: CASSANDRA-21160
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21160
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Feature/Vector Search
> Reporter: Michael Marshall
> Priority: Normal
>
> The `VectorMemoryIndex` supports asynchronous additions to the graph.
> However, the `synchronous` keyword for the `add` method prevents this and
> therefore means we are adding a point of contention that is unnecessary.
> As part of this ticket, we should verify my understanding that writes can be
> concurrent and then drop the keyword.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
