Professional Web Applications Themes

Will Thread blocking in read() leads to process blocking? - UNIX Programming

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 ...

  1. #1

    Default Re: Will Thread blocking in read() leads to process blocking?

    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.
    Loic Domaigne Guest

  2. #2

    Default Re: Will Thread blocking in read() leads to process blocking?

    In article <3e0374e6.0307161452.579a22fcposting.google.com >,
    Loic Domaigne <loic-devgmx.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...
    Steve Watt Guest

  3. #3

    Default Re: Will Thread blocking in read() leads to process blocking?

    [email]mruusers.sourceforge.net[/email] (Måns Rullgård) wrote in message news:<yw1xvfu24hln.fsfusers.sourceforge.net>...
    > [email]qazmlp1209rediffmail.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.
    qazmlp Guest

  4. #4

    Default Re: Will Thread blocking in read() leads to process blocking?

    In article <db9bbf31.0307162015.463881cdposting.google.com >,
    qazmlp <qazmlp1209rediffmail.com> wrote:
    % [email]mruusers.sourceforge.net[/email] (Måns Rullgård) wrote in message
    % news:<yw1xvfu24hln.fsfusers.sourceforge.net>...
    % > [email]qazmlp1209rediffmail.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]ptjminterlog.com[/email]
    Patrick TJ McPhee Guest

  5. #5

    Default Re: Will Thread blocking in read() leads to process blocking?

    Steve Watt wrote:
    > In article <3e0374e6.0307161452.579a22fcposting.google.com >,
    > Loic Domaigne <loic-devgmx.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.Butenhofhp.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] ]---/
    David Butenhof Guest

Similar Threads

  1. Blocking IP Range
    By orgwicked in forum Dreamweaver AppDev
    Replies: 1
    Last Post: March 6th, 05:44 PM
  2. ReceiveNextEvent Blocking
    By Steven Walker in forum Mac Programming
    Replies: 0
    Last Post: July 21st, 07:36 PM
  3. Pop-Up Blocking
    By TL Willis in forum Windows Setup, Administration & Security
    Replies: 3
    Last Post: July 21st, 06:25 AM
  4. Blocking Refresh
    By Atrax in forum ASP Components
    Replies: 1
    Last Post: July 18th, 09:11 PM
  5. pipe - non blocking read? (fork/Win32)
    By Stuart Moore in forum PERL Miscellaneous
    Replies: 6
    Last Post: July 7th, 03:53 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139