apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: cvs commit: apr/threadproc/unix thread.c
Date Fri, 03 Aug 2001 07:11:05 GMT
On Thu, Aug 02, 2001 at 08:25:33PM -0700, Justin Erenkrantz wrote:
> On Thu, Aug 02, 2001 at 07:46:38PM -0700, Ian Holsman wrote:
> > just a note for the person wanting to implement this in unix.
> > 
> > in linux .. pthread_yield would be OK.
> > in solaris thr_yield should be used (as pthread_yield isn't defined, and 
> > posix threads are implemented onto of LWP threads )
> > 
> > Justin/Aaron ???
> We'd probably want sched_yield as this is what POSIX.1b (aka POSIX.4)
> specifies.

Ian is correct, sched_yield is for processes.

> FWIW, I think implementing this flies in the face of the OS scheduler 
> (and on Solaris, the user scheduler which handles the LWP threads).  
> The OS should do all of this for us.  NetWare seems to have a poor 
> scheduler, so it needs a little help.

The usage of a thread-level yield is really orthogonal to the
performance characteristics of the OS scheduler, even on two-level
systems like Solaris. In all cases (one-level or two-level), thread
libraries will at some point have to multiplex one kernel-level
thread (aka LWP) across many user-space threads. If it happens to
do this multiplexing on calls like blocking-IO, then that is ideal,
but like the Netware guys pointed out, cpu-bound blocks that do
not make any of the magic thread-multiplexing system calls will
not yield the cpu to it's peer threads.

thread_yield is not really anything more than allowing the thread
library to switch to a higher-priority thread. If there are no
higher-priority threads, this is a really low impact function.

> Unless someone can show a win on Unix, I'd rather see this left
> unimplemented.  It should almost be #define to NULL on Unix rather 
> than an empty function (so the compiler can easily optimize it out).

UNIX != preemptive thread libraries. There are quite a few thread
libraries out there that are totally portable and non-preemptive
(GNU Pth for example). If we go ahead and #define apr_thread_yield()
to NULL on UNIX, we effectively prevent anyone from using these
libraries for apache.

> My problem isn't with this call, but with the use of this call.
> Since I believe the NetWare guys intend to sprinkle this throughout 
> the httpd code, I'd like to make sure that this code is a no-op on
> Unix.  If someone can show where this is a win with a good OS 
> scheduler, I'd love to hear about it.  I'm not seeing the advantage.

Again, it has nothing to do with the OS scheduler, but everything
to do with thread-friendly code. If you're that worried about the
impact of this function, we should run some performance tests
(with flood :) and profile the server.

-aaron +1*0 (the 0 is because i'm a non-commiter ;)

View raw message