Replaced topic lock by atomic boolean to avoid lock contention #495
Conversation
aratz-lasa
force-pushed
the
feature/lockless-topic
branch
from
1b89826
to
780ebac
Compare
|
I ran Lock contention occurs because the pubsub producers go faster than the time it takes to sign with Ed25519, therefore, they end up queueing up, since they cannot enter the publish call until the lock is free. What do you mean by "it's not entirely the same"? |
|
its an RLock, so they should not content, they can hold it concurrently. It is not entirely the same because an active publish would prevent the topic from being closed concurrently. |
|
Let me think about it a bit. I dont think there will be any deleterious effects from the change, but it is still a change in behaviour. |
|
Aaah you are right! I thought that the |
| t.mux.Lock() | ||
| defer t.mux.Unlock() | ||
| if t.closed { | ||
| if t.closed.Load() { |
There was a problem hiding this comment.
There is a race here: you want to do Swap here and if old result was false then proceed with closing.
Otherwise 2 goroutines can hit Close, load false and proceed.
PR opened in response to #494.
In the
topicstruct, there is currently lock contention due to the internal lock that is used to check if the topic has been closed or not. This generates lock contention, in those cases where thepublishcall takes a long time, such as if messages are signed with RSA.Therefore, in this PR is proposed to replace the lock with an atomic boolean, allowing concurrent calls to Publish, and relieving lock contention.