5

I'm in a course on operating systems and we're talking about threading. On Wikipedia here it says that for 1:N kernel threads:

If one of the threads needs to execute an I/O request, the whole process is blocked and the threading advantage cannot be utilized

However this got me thinking. In C, if I create as UI on the main thread and if I do my I/O on a new thread with pthread then my UI wont block. Doesn't this contradict what Wikipedia says though because I still only have 1 process with 2 threads, so shouldn't my I/O thread block my UI according to what Wikipedia is saying?

edit: And if Windows and OS X use the 1:1 model as Wikipedia claims, then why in OSX when I do the top command or in Windows use task manager do I not see separate processes for each of my program's threads, why do I still see the multiple threads as listed under the 1 process?

user2333700
  • 127
  • 1
  • 5
  • 2
    Your observation just means that you have the wrong idea which of the thread model your platform has, it is certainly not N:1. **After your edit**: please don't change your question substantially, even before anybody had a chance to answer it. Generally, perhaps you should prepare your question a bit better before posting it. – Jens Gustedt Feb 25 '15 at 16:26
  • you can tell top, once it is running, to display each thread separately . click on the top window, then click 'h' to get the help info displayed – user3629249 Feb 25 '15 at 19:07

2 Answers2

12

Wikipedia is referring to user-level threading, wherein an entire group of threads is assigned to a single kernel thread. So when one of the threads does an I/O operation, control passes to the kernel, and the kernel thread will block while waiting for the I/O operation to complete. But since each thread in the group maps to that same kernel thread, the rest of the threads will block as well.

Pthreads on the other hand are not user-level threads. Each pthread is mapped to a different thread (process) in the kernel, and the kernel is responsible for scheduling the threads. If your GUI application creates a new pthread that does an I/O operation, the thread won't block the main application because they are different threads in the kernel.

As for your edit: the reason you see the number of threads under a specific process is that each thread group has a parent thread that started the process and created the threads. In your example it would be the GUI application - each thread it spawned would "point" to it (the implementation is specific to the OS, Linux for example has the tgid field which is the pid of the parent thread). You're usually interested in the performance of a process rather than a specific thread, so the data of all the threads is aggregated under the parent thread.

Daniel Kleinstein
  • 5,262
  • 1
  • 22
  • 39
  • Similar question is [here](https://stackoverflow.com/questions/46902158/java-io-bound-thread) – overexchange Oct 24 '17 at 04:51
  • "But since each thread in the group maps to that same kernel thread, the rest of the threads will block as well." I didn't get why is this so? – thepurpleowl Jun 20 '19 at 13:30
  • Probably I got the answer - https://stackoverflow.com/questions/40877998/why-blocking-system-calls-blocks-entire-procedure-with-user-level-threads – thepurpleowl Jun 20 '19 at 13:34
-1

My first thought is that statement you've quoted from Wiki is incorrect. One of the main reasons for using threads is specifically so I/O operations don't block the entire process.

Mike Waldron
  • 334
  • 2
  • 10