[SERVER-32242] Fix race in CompatibleFirstStress lock manager test Created: 08/Dec/17  Updated: 30/Oct/23  Resolved: 11/Dec/17

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 3.7.1
Fix Version/s: 3.4.11, 3.6.2, 3.7.1

Type: Improvement Priority: Trivial - P5
Reporter: Geert Bosch Assignee: Geert Bosch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Backport Requested:
v3.6, v3.4
Sprint: Storage 2017-12-18
Participants:
Linked BF Score: 0

 Description   

A call to lockComplete with timeout 0 may return LOCK_WAITING even though another thread already was notified. So the invariant that lockComplete must succeed if another thread is holding a MODE_S lock is invalid.

 



 Comments   
Comment by Githook User [ 03/Jan/18 ]

Author:

{'name': 'Geert Bosch', 'username': 'GeertBosch', 'email': 'geert@mongodb.com'}

Message: SERVER-32242 Fix race in CompatibleFirstStress lock manager test

(cherry picked from commit cc13cb76a07a01cb0eb14bd4516a9ef9c073f1c7)
Branch: v3.4
https://github.com/mongodb/mongo/commit/707f2e26f01bc9fa126877a275486f80f58ab004

Comment by Githook User [ 03/Jan/18 ]

Author:

{'name': 'Geert Bosch', 'username': 'GeertBosch', 'email': 'geert@mongodb.com'}

Message: SERVER-32242 Fix race in CompatibleFirstStress lock manager test

(cherry picked from commit cc13cb76a07a01cb0eb14bd4516a9ef9c073f1c7)
Branch: v3.6
https://github.com/mongodb/mongo/commit/3dd94e853f1f6e682cad15fdc3c4b1351cfca2c9

Comment by Githook User [ 11/Dec/17 ]

Author:

{'name': 'Geert Bosch', 'email': 'geert@mongodb.com', 'username': 'GeertBosch'}

Message: SERVER-32242 Fix race in CompatibleFirstStress lock manager test
Branch: master
https://github.com/mongodb/mongo/commit/cc13cb76a07a01cb0eb14bd4516a9ef9c073f1c7

Comment by Geert Bosch [ 08/Dec/17 ]

The situation here is that we have two threads A and B waiting for a lock. A receives notification of the lock grant, and tells B. Now B tries to wait for its lock with a timeout of 0 ms, but it receives LOCK_TIMEOUT. This can happen because by the time we synchronize with the lock bucket to remove our request, we don't check to see if it was granted after all. As we don't know of any real reason to fix the lock manager to avoid this tiny unfairness, fix the test instead.

Generated at Thu Feb 08 04:29:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.