Should I just believe that std::thread is implemented not by creating user threads only?

Question

I learned that all of user threads mapped with a kernel thread be blocked if one of the threads calls some system call likes I/O System Call.

If std::thread is implemented by creating only a user thread in some environment, then a thread for I/O in some programs can block a thread for Rendering.

So I think distinguishing user / kernel is important but c++ standard does not.

Then how I assure that some situations like above will not occur in particular environment(like Windows10 )?

Answer 1

Rephrasing my attempt to answer, after talking to the OP and understanding better what is really being asked.

Most I/O operations are blocking per thread level: if a threads starts one, only this thread will be blocked, not the whole process.

The OP seems to intend to start a rendering operation in a thread and doesn't want it to be blocked by an I/O operation in this thread. Two possible solutions are:

1. To spawn another thread to do this blocking I/O operation, and then let the rendering thread to proceed independently of the I/O;
2. To use resources specific of each OS (that doesn't belong to C++), to start the same I/O operation in an asynchronous, non blocking form.
3. Lastly, to minimize the blocking of the OS access to I/O, what an application developer can do is to try to make sure that there's no simultaneous access to the same I/O device at the same time.

Answer 2

You can be assured that std::thread is not using "user threads" because that concept pretty much died around the turn of the century.

Modern hardware has multiple CPU cores, which work much better if there are sufficient kernel threads. Without enough kernel threads, CPU cores may sit idle.

The idea of "user threads" originated in an era when there was only a single CPU core, and people instead worried about having too many kernel threads.