Sending unlock messages in a go-routine makes ``DRWMutex.[R]Lock()`` racy about dsync

[fwessels]

In Step 3, if nodes 2 & 3 would also grant the lock than quorum would be met and the lock would be granted (even if node 4 is still in blocked/network error state).
There is a (small) backoff window before trying to lock again, depending on timing it could be suboptimal in terms of number of messages, but it would not lead to incorrect behavior, right?

[krisis]

@fwessels, the lock mentioned in step 3 on "test' is different from the lock mentioned in step 1. I am not referring to the lock messages that appear out of retrying due to previous attempts at failing to lock. Does it make sense now?

[fwessels]

I see, this order of events can indeed happen.

[fwessels]

While the above order of events can maybe lead to not the most efficient way of dealing with it, it should not lead to incorrect behaviour (bugs).

One can also think of other scenarios that show correct behaviour but are suboptimal in terms of eg number of messages exchanged. While it is probably possible to optimize these scenarios it would complicate the code (and hence maybe introduce new bugs), so I think this is not worth the effort (and risk).