httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: ANNOUNCE: GNU Portable Threads (Pth) 1.2.0 released
Date Fri, 12 Nov 1999 07:17:44 GMT

In article <211201bf2b90$d475fb10$1e80000a@avantgo.com> you wrote:
> Ralf S. Engelschall <rse@engelschall.com> wrote:
>>   The thread scheduling itself is done in a cooperative way, i.e., the
>>   threads are managed by a priority- and event-based non-preemptive
>>   scheduler.
> <snip>
>>   PS: You can use GNU Pth as a drop-in replacement for a missing vendor
>>       Pthread library to run Apache 2.0 (with one of the threading MPMs
> like
>>       dexter) and this way get a multithreaded Apache 2.0 running on
> usually
>>       all Unix platforms - ranging from mostly all ancient Unix flavors
> to
>>       really all the modern ones.
> 
> It seems to me that this only works so long as your modules are written
> with cooperative multithreading in mind.  If they simply go off and think
> for long periods of time, then, as described, Pth will not allow other
> threads to run.  Or am I missing something about your use of
> 'non-preemptive', here?
> 
> [Not trying to shoot you down, just pointing out that there's a potentially
> annoying hole in using Pth as your pthreads, versus using MIT pthreads, for
> instance.]

Yes, that's the main end-user visible difference between preemptive
multithreading and non-preemptive multithreading. It is as always in life: for
a benefit on the one side (here: great portability) you have to pay a price on
the other side (here: no preemption). So your observation is correct, of
course. If a modules performs very long CPU bursts this doesn't allow other
threads to work under Pth. Pth cannot do anything against this. OTOH one could
ask whether it is useful to allow modules to perform such long CPU bursts at
all ;)

BTW, in case you're interested in the background, the reason why Pth is
non-preemptive is intentionally and not just for fun. Because it is not
actually the implementation of preemptive scheduling and dispatching
which makes the trouble (for this, one mainly just needs a little bit
of OS support like SIGVTALRM, and the synchronization objects need a
real atomic lock, etc.). The main problems are caused more by auxilliary
things like the requirement of reentrant library functions, etc.

If you use non-preemptive multithreading you don't have to care about these
nasty things (this way Pth does not and has not to provide reentrant variants
of standard functions and also no mutex-wrapped system calls, etc.). If you
use preemptive scheduling you immediately open a can of such worms and it is
questionable whether it is worth the effort and resulting portability
drawbacks when doing user-space multithreading - just to also get preemptive
scheduling, which IMHO 95% the time isn't really required in well-designed
server applications...

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message