From the demo shown, if Pthreads is implemented using a thread pool (which I though it usually was) then why is there such large overhead for spawning "new" pthreads for each element - shouldn't Pthreads be able to avoid asking the OS for new threads for each pthread_create()?
arcticx
@ArbitorOfTheFountain OS guarantees to allocate stack space and maintain different context (registers) for each thread. Such overhead cannot be avoided.
sasthana
AFAIK there are multiple threading model. Like:
1:1 where for each user mode thread there is a kernel mode thread. So in such cases @arcticx's comment would hold true.
There are other threading model like M:1 and M:N where usually the number of user mode threads are more than the underlying kernel mode threads. In such cases there is a scheduling logic present at the pThread library level as well. But in this case, though not OS, but the pThread library would need to allocate thread control block for its threads, allocate context etc and thus there is a overhead.
ArbitorOfTheFountain
My question was based on the assumption that the pthread library specifies and interface which might be implemented using a M:N threading model with a thread pool of size N and M pthreads. If a 1:1 mapping is assumed @artix is correct.
Perhaps this indicates that the pthread library being used IS implemented with 1 kernel thread per pthread.
PIC
@ArbitorOfTheFountain
Yes pthreads is a 1:1 thread library. Think back to proxy lab. Each one of your threads invoked a BLOCKING system call (namely writing to a socket). Imagine what happens if every thread in a thread pool executes a blocking system. Then no thread can actually run. Imagine what happens if each thread called "sleep"!
Making M:N thread libraries "work" (meaning sleep does a sensible thing) actually incurs a massive amount of overhead and basically involves the library writers implementing basically another operating system (every system call requires a wrapper or some intervention by the run time). You can read online about what Go does if you're interested.
monkeyking
I am doing OS p2 in which I need to implement a thread library. I agree with PIC that a M:N thread libraries is much harder than a 1:1 one.
From the demo shown, if Pthreads is implemented using a thread pool (which I though it usually was) then why is there such large overhead for spawning "new" pthreads for each element - shouldn't Pthreads be able to avoid asking the OS for new threads for each pthread_create()?
@ArbitorOfTheFountain OS guarantees to allocate stack space and maintain different context (registers) for each thread. Such overhead cannot be avoided.
AFAIK there are multiple threading model. Like:
1:1 where for each user mode thread there is a kernel mode thread. So in such cases @arcticx's comment would hold true.
There are other threading model like M:1 and M:N where usually the number of user mode threads are more than the underlying kernel mode threads. In such cases there is a scheduling logic present at the pThread library level as well. But in this case, though not OS, but the pThread library would need to allocate thread control block for its threads, allocate context etc and thus there is a overhead.
My question was based on the assumption that the pthread library specifies and interface which might be implemented using a M:N threading model with a thread pool of size N and M pthreads. If a 1:1 mapping is assumed @artix is correct.
Perhaps this indicates that the pthread library being used IS implemented with 1 kernel thread per pthread.
@ArbitorOfTheFountain
Yes pthreads is a 1:1 thread library. Think back to proxy lab. Each one of your threads invoked a BLOCKING system call (namely writing to a socket). Imagine what happens if every thread in a thread pool executes a blocking system. Then no thread can actually run. Imagine what happens if each thread called "sleep"!
Making M:N thread libraries "work" (meaning sleep does a sensible thing) actually incurs a massive amount of overhead and basically involves the library writers implementing basically another operating system (every system call requires a wrapper or some intervention by the run time). You can read online about what Go does if you're interested.
I am doing OS p2 in which I need to implement a thread library. I agree with PIC that a M:N thread libraries is much harder than a 1:1 one.