Minix and threads - Minix

This is a discussion on Minix and threads - Minix ; As far as I know, Minix doesn't support kernel thread but I'm not sure if it can deal with user thread (posix). I'm wondering why it doesn't have kernel thread, the answer that I've given myself are: 1) Minix was ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Minix and threads

  1. Minix and threads


    As far as I know, Minix doesn't support kernel thread but I'm not sure
    if it can deal with user thread (posix). I'm wondering why it doesn't
    have kernel thread, the answer that I've given myself are:

    1) Minix was born as teaching operating system purpose and avoid using
    (kernel) thread is simpler to study (and develop)
    2)Thread are more difficult to be handled because of their nature
    (e.g. share the same memory data space) and in some sense they can
    make the entire operating system unreliable in contrast with one of
    the developers' goal, indeed on the minix 3 home page there is stated
    that Minix wants to be a reliable operating system.

    Do you agree with me?

  2. Re: Minix and threads

    puntino wrote:

    > As far as I know, Minix doesn't support kernel thread but I'm not sure
    > if it can deal with user thread (posix). I'm wondering why it doesn't
    > have kernel thread, the answer that I've given myself are:


    > 1) Minix was born as teaching operating system purpose and avoid using
    > (kernel) thread is simpler to study (and develop)


    True

    > 2)Thread are more difficult to be handled because of their nature
    > (e.g. share the same memory data space) and in some sense they can
    > make the entire operating system unreliable in contrast with one of
    > the developers' goal, indeed on the minix 3 home page there is stated
    > that Minix wants to be a reliable operating system.


    Minix does not use kernel threads because the kernel does very, very
    little. In Linux, every driver or other kernel module runs as part of the
    kernel. Drivers frequently block while waiting for a device to complete
    the issued operation. Blocking the kernel while waiting for I/O is
    unnacceptable in any modern interactive operating system, because it would
    basically halt the system until the I/O operation completes. Kernel
    threads fix this issue because a blocking thread does not block the entire
    kernel.

    All of Minix's drivers, file and networking services and other system
    components run as processes of their own. This means that a driver that
    blocks while waiting for I/O simply yields like any other regular process,
    allowing the system to continue operating unhindered. All of Minix' kernel
    operations complete in a very short time and thus do not require
    threading. Thread management would probably cause more overhead in the
    kernel than any performance gain could make up for.

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  3. Re: Minix and threads

    On Jun 2, 9:31 am, "J.F. de Smit" wrote:
    > puntino wrote:
    > > As far as I know, Minix doesn't support kernel thread but I'm not sure
    > > if it can deal with user thread (posix). I'm wondering why it doesn't
    > > have kernel thread, the answer that I've given myself are:
    > > 1) Minix was born as teaching operating system purpose and avoid using
    > > (kernel) thread is simpler to study (and develop)

    >
    > True
    >
    > > 2)Thread are more difficult to be handled because of their nature
    > > (e.g. share the same memory data space) and in some sense they can
    > > make the entire operating system unreliable in contrast with one of
    > > the developers' goal, indeed on the minix 3 home page there is stated
    > > that Minix wants to be a reliable operating system.

    >
    > Minix does not use kernel threads because the kernel does very, very
    > little. In Linux, every driver or other kernel module runs as part of the
    > kernel. Drivers frequently block while waiting for a device to complete
    > the issued operation. Blocking the kernel while waiting for I/O is
    > unnacceptable in any modern interactive operating system, because it would
    > basically halt the system until the I/O operation completes. Kernel
    > threads fix this issue because a blocking thread does not block the entire
    > kernel.
    >
    > All of Minix's drivers, file and networking services and other system
    > components run as processes of their own. This means that a driver that
    > blocks while waiting for I/O simply yields like any other regular process,
    > allowing the system to continue operating unhindered. All of Minix' kernel
    > operations complete in a very short time and thus do not require
    > threading. Thread management would probably cause more overhead in the
    > kernel than any performance gain could make up for.
    >
    > Regards,
    >
    > Jens
    >
    > --
    > Jens de Smit
    > Student Computer Science | Vrije Universiteit Amsterdam
    > jfds...@few.vu.nl |http://www.few.vu.nl/~jfdsmit
    > "[In the end, people] get furious at IT that the goddamn magic isn't working"
    > -- Stewart Dean


    Thank you Jens

  4. Re: Minix and threads

    puntino writes:
    > > All of Minix's drivers, file and networking services and other system
    > > components run as processes of their own. This means that a driver that
    > > blocks while waiting for I/O simply yields like any other regular process,
    > > allowing the system to continue operating unhindered. All of Minix' kernel
    > > operations complete in a very short time and thus do not require
    > > threading. Thread management would probably cause more overhead in the
    > > kernel than any performance gain could make up for.


    How about FS? In Minix 2, there was a hack for not blocking while
    waiting for input from TTYs, but FS did block on disk I/O. I don't think
    threads are the answer, because the required locking makes things way
    more complicated than a better design, but I haven't read so far that
    Minix 3 FS may handle more than one disk I/O request at once.

    Michael

  5. Re: Minix and threads

    In article <4843c8c8$0$25510$9b622d9e@news.freenet.de>,
    Michael Haardt wrote:
    >but I haven't read so far that
    >Minix 3 FS may handle more than one disk I/O request at once.


    There is now code for doing that, but it is nowhere near stable enough to be
    released.


    --
    That was it. Done. The faulty Monk was turned out into the desert where it
    could believe what it liked, including the idea that it had been hard done
    by. It was allowed to keep its horse, since horses were so cheap to make.
    -- Douglas Adams in Dirk Gently's Holistic Detective Agency

  6. Re: Minix and threads

    philip@ue.aioy.eu (Philip Homburg) writes:
    > In article <4843c8c8$0$25510$9b622d9e@news.freenet.de>,
    > Michael Haardt wrote:
    > >but I haven't read so far that
    > >Minix 3 FS may handle more than one disk I/O request at once.

    >
    > There is now code for doing that, but it is nowhere near stable enough to be
    > released.


    I am sure it is not easy, because solved without threads, it has serious
    implications on the communication patterns. But once that is worked out
    properly, Minix as a whole will benefit very much from the new capability.
    To me, that would be the greatest single improvement since VFS.

    The next thing, of course, would be a disk driver that handles more than
    one request at once, stacking drivers, and a RAID1 driver.

    Michael

  7. Re: Minix and threads

    Michael Haardt wrote:
    >> There is now code for doing that, but it is nowhere near stable enough to
    >> be released.


    For the not-so-faint of heart:

    https://gforge.cs.vu.nl/plugins/scms...fs/?root=minix

    > I am sure it is not easy, because solved without threads, it has serious
    > implications on the communication patterns. But once that is worked out
    > properly, Minix as a whole will benefit very much from the new capability.
    > To me, that would be the greatest single improvement since VFS.


    > The next thing, of course, would be a disk driver that handles more than
    > one request at once, stacking drivers, and a RAID1 driver.


    I would actually be more interested in wider file system support than
    better performance at this point and will once more make my case for
    porting Fuse as a first step. I'm willing to do some work on it after I
    complete my graduation (still some months away though) but I could really
    use some pointers from somebody more experienced in the field of Linux
    kernel module programming. I am completely unexperience in that particular
    craft and feel it will be the most challenging aspect of the project. The
    library system and fusemount program should be less platform-dependent and
    therefore easier to port. So, who's the big experienced Linux kernel
    hacker around here?

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  8. Re: Minix and threads

    On Jun 2, 9:31 am, "J.F. de Smit" wrote:
    > puntino wrote:
    > > As far as I know, Minix doesn't support kernel thread but I'm not sure
    > > if it can deal with user thread (posix). I'm wondering why it doesn't
    > > have kernel thread, the answer that I've given myself are:
    > > 1) Minix was born as teaching operating system purpose and avoid using
    > > (kernel) thread is simpler to study (and develop)

    >
    > True
    >
    > > 2)Thread are more difficult to be handled because of their nature
    > > (e.g. share the same memory data space) and in some sense they can
    > > make the entire operating system unreliable in contrast with one of
    > > the developers' goal, indeed on the minix 3 home page there is stated
    > > that Minix wants to be a reliable operating system.

    >
    > Minix does not use kernel threads because the kernel does very, very
    > little. In Linux, every driver or other kernel module runs as part of the
    > kernel. Drivers frequently block while waiting for a device to complete
    > the issued operation. Blocking the kernel while waiting for I/O is
    > unnacceptable in any modern interactive operating system, because it would
    > basically halt the system until the I/O operation completes. Kernel
    > threads fix this issue because a blocking thread does not block the entire
    > kernel.
    >
    > All of Minix's drivers, file and networking services and other system
    > components run as processes of their own. This means that a driver that
    > blocks while waiting for I/O simply yields like any other regular process,
    > allowing the system to continue operating unhindered. All of Minix' kernel
    > operations complete in a very short time and thus do not require
    > threading. Thread management would probably cause more overhead in the
    > kernel than any performance gain could make up for.
    >
    > Regards,
    >
    > Jens
    >
    > --
    > Jens de Smit
    > Student Computer Science | Vrije Universiteit Amsterdam
    > jfds...@few.vu.nl |http://www.few.vu.nl/~jfdsmit
    > "[In the end, people] get furious at IT that the goddamn magic isn't working"
    > -- Stewart Dean



  9. Re: Minix and threads

    On Jun 2, 9:31 am, "J.F. de Smit" wrote:
    > All of Minix' kernel
    > operations complete in a very short time and thus do not require
    > threading. Thread management would probably cause more overhead in the
    > kernel than any performance gain could make up for.
    >


    Yes but userspace processes would benefit from kernel threads
    implementation too,
    you can write multi thread programs that scale to an arbitrary number
    of cores.

  10. Re: Minix and threads

    Maurizio Lombardi wrote:
    > On Jun 2, 9:31 am, "J.F. de Smit" wrote:
    >> All of Minix' kernel
    >> operations complete in a very short time and thus do not require
    >> threading. Thread management would probably cause more overhead in the
    >> kernel than any performance gain could make up for.
    >>


    > Yes but userspace processes would benefit from kernel threads
    > implementation too,
    > you can write multi thread programs that scale to an arbitrary number
    > of cores.


    Don't confuse "kernel threads" and "thread support in the kernel"
    (although the former may be used to implement the latter). You need a
    thread-aware scheduler to be able to schedule userland threads on multiple
    cores, because a non-thread-aware scheduler will only schedule a process
    on one core at any time. However, it is not necessary to have a
    multithreaded kernel to be able to schedule multiple userland threads
    simultaneously. Some pthreads implementations do user kernel threads to
    facilitate user threads, but I don't think it is a requirement per se.

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  11. Re: Minix and threads

    On Jun 3, 1:20 pm, "J.F. de Smit" wrote:
    > Don't confuse "kernel threads" and "thread support in the kernel"
    > (although the former may be used to implement the latter). You need a
    > thread-aware scheduler to be able to schedule userland threads on multiple
    > cores, because a non-thread-aware scheduler will only schedule a process
    > on one core at any time. However, it is not necessary to have a
    > multithreaded kernel to be able to schedule multiple userland threads
    > simultaneously. Some pthreads implementations do user kernel threads to
    > facilitate user threads, but I don't think it is a requirement per se.
    >


    Yes, you are right. I was confusing "kernel threads" with "in kernel
    threads support".

    So i agree, because of the very limited amount of work the kernel does
    there is not a good reason to implement kernel threads

  12. Re: Minix and threads

    On 2008-06-03, Maurizio Lombardi expressed:
    > On Jun 3, 1:20 pm, "J.F. de Smit" wrote:
    >> Don't confuse "kernel threads" and "thread support in the kernel"
    >> (although the former may be used to implement the latter). You need a
    >> thread-aware scheduler to be able to schedule userland threads on multiple
    >> cores, because a non-thread-aware scheduler will only schedule a process
    >> on one core at any time. However, it is not necessary to have a
    >> multithreaded kernel to be able to schedule multiple userland threads
    >> simultaneously. Some pthreads implementations do user kernel threads to
    >> facilitate user threads, but I don't think it is a requirement per se.
    >>

    >
    > Yes, you are right. I was confusing "kernel threads" with "in kernel
    > threads support".


    The fundamental difference between processes and threads are not that
    big. The only difference is the entry in the process-table. It's no
    problem to do the scheduling of the threads inside the process(threads
    as userspace processes).

    The only kernel support you need is an alarm-signal to switch threads
    (the rest can be done with setjmp's and longjmps).

    Greetings,
    Frank

+ Reply to Thread