[SERVER-27896] Develop compiletime or runtime guarantees for calls to single-thread context functions. Created: 02/Feb/17 Updated: 02/Mar/20 Resolved: 02/Mar/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | ADAM Martin (Inactive) | Assignee: | Amirsaman Memaripour |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Service Arch 2020-02-10, Service Arch 2020-02-24, Service Arch 2020-03-09 |
| Participants: |
| Description |
|
There are myriad functions that are only safe to call in single-threaded context, such as by Mongo initializer code. Two alternative designs here: 1. stdx::thread uses a std::once initialization to transition a global boolean to false, indicating that the system is (potentially) no longer single threaded. Initialization and similar functions can assert on this global boolean (via an observer.) 2. Create an object which is constructible only by `int main(...)`, and pass this object to initializer functions by const reference. When main is going to launch its first thread, call into a `multithread_main` function which does not take the `SingleThreaded` mode object (token) as an argument – thus making it buried (and lost forever) in main. The first design is simple to implement, but it is a runtime-check. The second design is a partial compile-time guarantee of threading concerns. |
| Comments |
| Comment by Githook User [ 02/Mar/20 ] |
|
Author: {'username': 'samanca', 'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@mongodb.com'}Message: |
| Comment by Amirsaman Memaripour [ 25/Feb/20 ] |
|
Sure, we'll do that. |
| Comment by Andy Schwerin [ 24/Feb/20 ] |
|
I’d also like to get the ability to prohibit thread creation before a certain point in startup. Easier to debug than having the invariant trip when you call the single-thread-context function. I think a more common problem we have is starting threads earlier than intended, rather than calling pre-thread functions later than intended. Can we get that while we’re in here? |
| Comment by A. Jesse Jiryu Davis [ 21/May/19 ] |
|
Jason Carey has prototyped a gadget that does the runtime check. |