[CSHARP-188] Deadlock possible between BsonDefaultSerializer and BsonClassMap when classes are AutoMapped on the fly Created: 31/Mar/11  Updated: 02/Apr/15  Resolved: 31/Mar/11

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 1.0
Fix Version/s: 1.1

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

Attachments: Text File Program.cs    

 Description   

In a heavily multithreaded environment it is possible to get a deadlock between threads when classes are AutoMapped on the fly as needed.

Sample program to reproduce attached. Must add a 1 second sleep to BsonDefaultSerializer.LookupActualType right after the lock on staticLock is acquired to have high probability of encountering the deadlock (the deadlock can occur without the sleep but with such low probability that it would be harder to reproduce).



 Comments   
Comment by Robert Stam [ 01/Apr/11 ]

Further removed any possiblity of deadlock by changing the three thread-safe serialization classes (BsonSerializer, BsonDefaultSerializer and BsonClassMap) to share a single static ConfigLock.

As an aside: I don't consider it worthwhile to try to use a ReaderWriterLockSlim here instead. The reason is that the exclusive lock is released very quickly (unless some configuration has to happen, but that only happens once). Therefore the extra complexity of using ReaderWriterLockSlim just wouldn't be worth it.

Comment by Robert Stam [ 31/Mar/11 ]

Fixed by calling LookupClassMap outside of the lock in BsonDefaultSerializer. Also improved implementation to only call LookupClassMap if it is necessary.

Generated at Wed Feb 07 21:36:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.