[SERVER-1762] deadlock between db mutex and js mutex Created: 09/Sep/10  Updated: 29/Aug/11  Resolved: 17/Mar/11

Status: Closed
Project: Core Server
Component/s: JavaScript
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Aaron Staple Assignee: Eliot Horowitz (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-1756 hang during parallel tests Closed
Operating System: ALL
Participants:

 Description   

There is a reachable deadlock condition between the db mutex and js mutex, which has been seen in v8 (SERVER-1756). The same issue may affect spidermonkey, as a spidermonkey mutex guards all sm calls.

To fix, all javascript calls from c++ must occur while a db mutex is held. In the diagnosed case, javascript calls within MRState::MRState() were made without a db mutex. These calls held the v8 mutex and requested the db mutex, while a concurrent db.eval held the db mutex and requested the v8 mutex.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 17/Mar/11 ]

Switching to v8

Comment by Eliot Horowitz (Inactive) [ 03/Jan/11 ]

If we switch to v8 may not have to worry.

Comment by auto [ 13/Sep/10 ]

Author:

{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}

Message: SERVER-1762 clean up v8 mutex usage somewhat
http://github.com/mongodb/mongo/commit/e47687bd03132c4c526ff61754eb8634fd9661a1

Comment by Aaron Staple [ 09/Sep/10 ]

Yeah we can fix it that way too, and I should have thought of and mentioned that. I was just thinking that it might be easier to ensure correct behavior by getting a db mutex before doing anything with js than it would be to check the various callbacks in the js implementations to see if they need a db lock. But obviously if anything time consuming is going to happen in js it would be best to do it without the db lock when that's possible.

Right now the v8 implementation does unlock for the major db operations (this is what allows concurrent threads in the shell). It looks like it was not unlocking for loadStored(), which puts variables inside the system.js namespace, and I think this is what was triggering SERVER-1756. I'll see if I can find any other callbacks that can grab a db lock and handle those too.

Comment by auto [ 09/Sep/10 ]

Author:

{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}

Message: SERVER-1762 don't call loadStored() with v8 mutex
http://github.com/mongodb/mongo/commit/9221b81acb863672eef708d052ad68c9d7aa83f0

Comment by Eliot Horowitz (Inactive) [ 09/Sep/10 ]

This is definitely true for spidermonkey.

For v8 - can't we handle inside v8?
I though we unlocked when we left v8 and went back into the db?
Since v8 is "thread safe" should be able to not require a db lock, right?

If so - can you fix v8 and then re-assign to me?

Generated at Thu Feb 08 02:57:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.