Daniel Eischen 596ea21c7f Add a preemption point when a mutex or condition variable is ... handed-off/signaled to a higher priority thread. Note that when there are idle KSEs that could run the higher priority thread, we still add the preemption point because it seems to take the kernel a while to schedule an idle KSE. The drawbacks are that threads will be swapped more often between CPUs (KSEs) and that there will be an extra userland context switch (the idle KSE is still woken and will probably resume the preempted thread). We'll revisit this if and when idle CPU/KSE wakeup times improve. Inspired by: Petri Helenius <pete@he.iki.fi> Reviewed by: davidxu		2003-07-18 02:46:30 +00:00
..
arch	Clean up KSE specific data (KSD) macros a bit.	2003-07-18 02:45:56 +00:00
man	The .Fn function	2003-06-08 10:40:44 +00:00
support	Style.	2003-07-02 20:52:39 +00:00
sys	Move the machine specific files from sys/Makefile.inc and put them	2003-06-23 04:28:31 +00:00
test	o Eliminate upcall for PTHREAD_SYSTEM_SCOPE thread, now it	2003-07-17 23:02:30 +00:00
thread	Add a preemption point when a mutex or condition variable is	2003-07-18 02:46:30 +00:00
Makefile	o Eliminate upcall for PTHREAD_SYSTEM_SCOPE thread, now it	2003-07-17 23:02:30 +00:00
pthread.map	o Use a daemon thread to monitor signal events in kernel, if pending	2003-06-28 09:55:02 +00:00