[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: SERVER-27896 Add support for enforcing single-thread context
Branch: master
https://github.com/mongodb/mongo/commit/5a3dd86b2e06a065ba435e4a6fe69300d0ba73a0

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.

Generated at Thu Feb 08 04:16:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.