[SERVER-20234] Async MockStream's race in unblock Created: 31/Aug/15  Updated: 19/Sep/15  Resolved: 31/Aug/15

Status: Closed
Project: Core Server
Component/s: Networking
Affects Version/s: 3.1.7
Fix Version/s: 3.1.8

Type: Bug Priority: Major - P3
Reporter: Mira Carey Assignee: Mira Carey
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Run network_interface_asio_test with a bunch of background threads (enough to saturate the scheduler)

Sprint: Platform 9 (09/18/15)
Participants:
Linked BF Score: 0

 Description   

AsyncMockStreamFactor::MockStream::unblock() drops its lock to unblock consuming threads. Then it re-acquires the lock before returning.

Under enough contention, this can lead simulateServer to attempt to re-acquire a lock that has just gotten deleted if completeOperation finishes within NetworkInterfaceASIO in time.

The solution is to avoid dropping the lock for the notify.



 Comments   
Comment by Githook User [ 31/Aug/15 ]

Author:

{u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}

Message: SERVER-20234 Async MockStream's race in unblock

AsyncMockStreamFactor::MockStream::unblock() drops its lock to unblock
consuming threads. Then it re-acquires the lock before returning.

Under enough contention, this can lead simulateServer to attempt to
re-acquire a lock that has just gotten deleted if completeOperation
finishes within NetworkInterfaceASIO in time.

The solution is to avoid dropping the lock for the notify.
Branch: master
https://github.com/mongodb/mongo/commit/78f7878663828b5fb70d102a338a32dd91ac2cea

Generated at Thu Feb 08 03:53:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.