Will Thread blocking in read() leads to process blocking?

[Loic Domaigne]

Hi!

> > If one thread is blocking in read() call, can other thread in the same
> > process run at the same time?
> > I just want to know, whether blocking in read() call is actually
> > blocking the whole process.

>
> It depends on your threads implementation. What are you using? POSIX
> pthreads does not block the whole process.

Yes, the outcome depends on the threads implementation. However, it is
incorrect to believe that a POSIX conformant implementation won't
block the whole process. In fact, everything depends on "how much does
the kernel scheduler know about threads".

There is 3 common models for threads implementation:

- "M to 1" or "user space" model: The notion of threads is only known
by the threads library. The threads are scheduled by the library
itself. On the kernel side, the whole MT-process is viewed as "one
process". IOW, the kernel has no notion of "threads". Unless the
library provides some wrappers for the system calls, if one thread
issues a blocking system call, it is likely that the whole process
gets blocked.

- "1 to 1" model: to each thread in the process is a kernel thread
associated with. It that latter case, when a thread blocks in a system
call, only that particular thread goes to the "suspend state". The
other threads get scheduled as normal, and if one is runnable, it will
acquire the CPU. As a result the whole process isn't blocked.

- "M to N" aka "2 level scheduler" model: This is a mix between the
two previous models. M threads are mapped to N kernel threads, with
eventually M > N. This means that a kernel thread might be responsible
for 2 or more threads of the process. The same problem might occurred
as for the "M to 1" model. However, some implementations like Solaris
(a well known two level implementation) use some tricks, in other to
avoid that the all the LWPs mapped to one kernel thread gets blocked.

In conclusion: You can only answer that question if you know the model
implemented by the Pthreads lib, or experiment if you don't. If you
tell us the OS / Pthreads implementation used, this should be
sufficient to give you the exact answer.


HTH,
Loic.

[Steve Watt]

In article <3e0374e6.0307161452.579a22fc@posting.google.com >,
Loic Domaigne <loic-dev@gmx.net> wrote:

>Hi!
>

>> > If one thread is blocking in read() call, can other thread in the same
>> > process run at the same time?
>> > I just want to know, whether blocking in read() call is actually
>> > blocking the whole process.

>>
>> It depends on your threads implementation. What are you using? POSIX
>> pthreads does not block the whole process.

>
>
>Yes, the outcome depends on the threads implementation. However, it is
>incorrect to believe that a POSIX conformant implementation won't
>block the whole process. In fact, everything depends on "how much does
>the kernel scheduler know about threads".

Actually, if it's POSIX conformant, a thread absolutely MUST NOT be able
to block the rest of the threads by calling a POSIX API function.

>There is 3 common models for threads implementation:
>
>- "M to 1" or "user space" model: The notion of threads is only known
>by the threads library. The threads are scheduled by the library
>itself. On the kernel side, the whole MT-process is viewed as "one
>process". IOW, the kernel has no notion of "threads". Unless the
>library provides some wrappers for the system calls, if one thread
>issues a blocking system call, it is likely that the whole process
>gets blocked.

If such a library is attempting to be POSIX, it will have provided
wrappers for all such functions.

>- "1 to 1" model: to each thread in the process is a kernel thread
>associated with. It that latter case, when a thread blocks in a system
>call, only that particular thread goes to the "suspend state". The
>other threads get scheduled as normal, and if one is runnable, it will
>acquire the CPU. As a result the whole process isn't blocked.
>
>- "M to N" aka "2 level scheduler" model: This is a mix between the
>two previous models. M threads are mapped to N kernel threads, with
>eventually M > N. This means that a kernel thread might be responsible
>for 2 or more threads of the process. The same problem might occurred
>as for the "M to 1" model. However, some implementations like Solaris
>(a well known two level implementation) use some tricks, in other to
>avoid that the all the LWPs mapped to one kernel thread gets blocked.

Actually, Solaris' current implementation is 1 to 1. It's astonishingly
hard to get MxN thread scheduling working correctly, and Sun finally
stopped trying. This is probably a good thing, in the long run.

>In conclusion: You can only answer that question if you know the model
>implemented by the Pthreads lib, or experiment if you don't. If you
>tell us the OS / Pthreads implementation used, this should be
>sufficient to give you the exact answer.

The only threads package in wide use (that I'm aware of) in which a
single thread can block the whole process is GNU Pth. And there
are even optional wrappers there for most platforms.

It's extremely rare to find such a hopelessly broken thread
implementation (i.e. one that allows such blocking) these days.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...

[qazmlp]

[email]mru@users.sourceforge.net[/email] (Måns Rullgård) wrote in message news:<yw1xvfu24hln.fsf@users.sourceforge.net>...

> [email]qazmlp1209@rediffmail.com[/email] (qazmlp) writes:
>

> > If one thread is blocking in read() call, can other thread in the same
> > process run at the same time?
> > I just want to know, whether blocking in read() call is actually
> > blocking the whole process.

>
> It depends on your threads implementation. What are you using? POSIX
> pthreads does not block the whole process.

I am using pthread library in Solaris.
I hope that makes my question to be unambiguous.

[Patrick TJ McPhee]

In article <db9bbf31.0307162015.463881cd@posting.google.com >,
qazmlp <qazmlp1209@rediffmail.com> wrote:
% [email]mru@users.sourceforge.net[/email] (Måns Rullgård) wrote in message
% news:<yw1xvfu24hln.fsf@users.sourceforge.net>...
% > [email]qazmlp1209@rediffmail.com[/email] (qazmlp) writes:
% >
% > > If one thread is blocking in read() call, can other thread in the same
% > > process run at the same time?
% > > I just want to know, whether blocking in read() call is actually
% > > blocking the whole process.
% >
% > It depends on your threads implementation. What are you using? POSIX
% > pthreads does not block the whole process.
%
% I am using pthread library in Solaris.
% I hope that makes my question to be unambiguous.

In this case, blocking in a read() call will not prevent other threads
from running.
--

Patrick TJ McPhee
East York Canada
[email]ptjm@interlog.com[/email]

[David Butenhof]

Steve Watt wrote:

> In article <3e0374e6.0307161452.579a22fc@posting.google.com >,
> Loic Domaigne <loic-dev@gmx.net> wrote:

>>
>>Yes, the outcome depends on the threads implementation. However, it is
>>incorrect to believe that a POSIX conformant implementation won't
>>block the whole process. In fact, everything depends on "how much does
>>the kernel scheduler know about threads".

>
> Actually, if it's POSIX conformant, a thread absolutely MUST NOT be able
> to block the rest of the threads by calling a POSIX API function.

This is critical. Any implementation that allows ANY blocking operation in
one thread to block progress of other threads in the process is NOT "POSIX
threads". It may implement the interfaces, but it's a fake.

>>- "M to N" aka "2 level scheduler" model: This is a mix between the
>>two previous models. M threads are mapped to N kernel threads, with
>>eventually M > N. This means that a kernel thread might be responsible
>>for 2 or more threads of the process. The same problem might occurred
>>as for the "M to 1" model. However, some implementations like Solaris
>>(a well known two level implementation) use some tricks, in other to
>>avoid that the all the LWPs mapped to one kernel thread gets blocked.

>
> Actually, Solaris' current implementation is 1 to 1. It's astonishingly
> hard to get MxN thread scheduling working correctly, and Sun finally
> stopped trying. This is probably a good thing, in the long run.

Yes, it is hard to get M:N working right, though there are real advantages.
(System Software development is not generally dedicated to the principle of
avoiding "hard" problems, after all.) But the history of Sun's trouble with
M:N isn't nearly as much technical as political. Even when developers tried
to address design problems, they weren't allowed. So, yes, giving up on M:N
probably was the best course, for Sun. M:N isn't something that can be done
halfway -- you either commit to the whole thing and follow through, or
you're better off not trying. Unlike Solaris, the Tru64 UNIX M:N scheduling
model was actually designed to work, and does. It (like all else) isn't
perfect, but it scales, it supports detailed and effective debugging, and
it's cleanly and deeply integrated with the kernel.

>>In conclusion: You can only answer that question if you know the model
>>implemented by the Pthreads lib, or experiment if you don't. If you
>>tell us the OS / Pthreads implementation used, this should be
>>sufficient to give you the exact answer.

If it claims to be POSIX threads, and it's possible for a blocking thread to
(in POSIX language) "prevent other threads from making progress", then
that's a BUG. They declared it a bug when they claimed to be POSIX: you
can't have it both ways. If they won't or can't fix the bozo
implementation, choose a real implementation instead. Would you continue to
use a word processor that arbitrarily deleted letters as you typed? Even if
your boss or customer insisted? (Of course, if your answer is "yes", well,
"there you go". ;-) )

--
/--------------------[ [email]David.Butenhof@hp.com[/email] ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: [url]http://www.awl.com/cseng/titles/0-201-63392-2/[/url] |
\----[ [url]http://homepage.mac.com/dbutenhof/Threads/Threads.html[/url] ]---/