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 ;)
