Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #2020

Re: Open issues in the specification for fork()?

Cross-posted to 2 groups.

Show key headers only | View raw

Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> writes:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:

[M:N/ 1:1 threading]

> The argument for "M:N is better" was very strong because, theoretically,
> it could be faster and synchronization wouldn't need to use the kernel.
>
> A "1:1" implementation, in practice, however, uncontended locks don't need a
> trip to the kernel either and the enormous amount of extra work needed in
> the MxN implementation (handling SIGWAITING, a second implementation of
> context switching, which actually often did require kernel involvement)

Some people think that 'threads are a way to structure programs', that
is, they're primarily supposed to be helpful for developers. The idea is
typically that 'a thread of execution' can be dedicated to a single task
which progresses intermittently and concurrently with a lot of other
tasks of the same kind: In a single-threaded process, this requires
storing the state of each task in some 'globally accessible' data
structure and continuing to work on some other tasks based on the
recorded state of that whenever the 'current task' can't make progress
anymore. If each task had a dedicated thread, this wouldn't
be necessary because 'the scheduler' would transparently suspend one
thread and switch to another whenever things would otherwise come to a
standstill, thus providing the illusion that each task really runs on a
dedicated computer without having to consider the needs of other tasks.

This, of course, requires creating as many threads as there are
concurrent tasks and for something like a network server, this could
easily mean thousands or even tenthousands of them. Consequently, each
thread needs to be as cheap as possible, in particular, it shouldn't
have any kernel resources like 'a kernel stack' permanently allocated to
it. Also, in order to make programming easy, actual concurrent
execution of threads should rather be avoided: For as long as a thread
is busy, it just keeps running, and once it invokes 'a blocking call' of
some kind, another thread can start to run. In order to avoid starving
tasks, threads are supposed to be 'nice to each other', that is,
explictly yield the processer every now and then when being busy for a
long time. This means cooperative userspace threading. Because there's
no concurrency, synchronization isn't really needed and because there's
no preemption, no complicated userspace scheduler is needed, either. At
least in theory. In practice, once the process blocks in the kernel, all
threads stop running and hence, each and every posssible blocking system
call must be wrapped in some library routine which accomplishes the same
end in some non-blocking way and runs other threads in the meantime. The
net effect of this is usually a lot of borderline insane library hackery
and some rather bizarre restrictions as to what a thread can do or must
not do (the GNU pth paper provides a nice example of that).

Some other people think that threads are supposed to be useful for users
in the sense that they enable these to utilize processing resources such
as multiple processors and/or multiple cores which might be available to
them. This implies that 'a thread' runs code which looks pretty much
like that of a single-threaded in processes wrt to
'multi-tasking'. In order to keep scheduling overhead down, there will
be relatively few threads (somewhat more than available 'processing
things') but they're both supposed to execute in parallell and to work
with 'shared global resources'. This means synchronization is needed and
the kernel scheduler has to deal with them because the kernel is the
privileged piece of coding managing the actual hardware and thus, the
only software capable of doing things like assigned threads to available
processors for execution. Further, this is supposed to work in an
environment shared with other application which also seek to use the
available resources and which don't have been written to cooperate,
hence, preemption is necessary. The most natural choice for this is 1:1
threading where each 'application thread' corresponds with a 'kernel
scheduled entity' of some sort.

Trying to satisfy both groups of people leads to M:N threading which
really just combines the disadvantages of both models without providing
the advantages of either. It ends up as expensive way to screw everyone
alike but only in practice, not in theory.

I was planning to illustrate this using the pre-Solaris 8/9 'threading
workarounds' as example but this text is too long already ...

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Open issues in the specification for fork()? Markus Elfring <Markus.Elfring@web.de> - 2013-11-23 19:05 +0100
  Re: Open issues in the specification for fork()? Måns Rullgård <mans@mansr.com> - 2013-11-23 18:32 +0000
  Re: Open issues in the specification for fork()? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2013-11-23 22:13 +0000
    Re: Open issues in the specification for fork()? Markus Elfring <Markus.Elfring@web.de> - 2013-11-24 06:56 +0100
  Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-24 10:27 +0000
    Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-24 15:39 +0000
      Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 00:23 +0000
        Re: Open issues in the specification for fork()? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2013-11-25 01:19 +0000
          Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 12:08 +0000
            Re: Open issues in the specification for fork()? Drazen Kacar <dave@fly.srk.fer.hr> - 2013-11-25 18:46 +0000
              Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 19:55 +0000
                Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 22:16 +0000
                Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-26 08:33 +0000
                Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-26 15:46 +0000
          Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 12:21 +0000
        Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 15:52 +0000
          Re: Open issues in the specification for fork()? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-11-25 16:55 +0000
            Re: Open issues in the specification for fork()? Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2013-11-25 17:36 +0000
  Re: Open issues in the specification for fork()? Kaz Kylheku <kaz@kylheku.com> - 2014-01-26 03:45 +0000

csiph-web