[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: |
|
| 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. |