[SERVER-40906] Add `StrongLock` primitive. Created: 30/Apr/19 Updated: 06/Dec/22 Resolved: 20/Aug/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | ADAM Martin (Inactive) | Assignee: | DO NOT USE - Backlog - Dev Tools |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Developer Tools
|
| Sprint: | Dev Tools 2019-06-03 |
| Participants: |
| Description |
|
The `StrongLock` primitive, discussed with ben.caimano, permits type system checked regions of locking and unlocking, along with immediate debugging runtime checks for ordering inversions. adam.martin@mongodb.com has a prototype implementation. |
| Comments |
| Comment by ADAM Martin (Inactive) [ 06/May/19 ] |
|
They would work in conjunction; `StrongLock` is to do something different than those thread safety analysis features do directly.. The `StrongLock` primitive would be used to permit nested locking-and-unlocking contexts, something Ben Caimano and I discussed. We'd eventually want to use the thread annotations too, and we'd make them work together, of course. |
| Comment by Max Hirschhorn [ 30/Apr/19 ] |
|
Is there a reason to prefer creating our own StrongLock primitive than leveraging the thread safety analysis features in clang? |