Date: Fri, 12 Nov 1999 01:33:02 -0700 From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com>, "freebsd-arch@FreeBSD.ORG" <freebsd-arch@freebsd.org> Subject: Re: Threads goals and implementation Message-ID: <199911120833.BAA17766@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9911112314520.17452-100000@current1.whistle.com> References: <382ABB1A.CB959F01@germany.sun.com> <Pine.BSF.4.10.9911112314520.17452-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 10/ A method to ask a thread blocked in the kernel to wake up and back > out (similar to present 'signals'). (see 6, 7) I think this is a good addition. > ---- possible userland implementation goals----- > > 1/ A libpthread that can be linked with libc. > > 2/ Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. > 3/ see 8 above. > --------------------------- > > Implementation: > > 1/ User-level thread scheduler that can perform user-level thread (ULT) > context switches. The ULT that is running on a KSE is completely > opaque to the kernel. > > 2/ The kernel provides KSEs to a process in which ULTs may be run. > Multiple KSEs may be provided to a process in order to achieve > simultaneous SMP executions and to allow ULTs to obtain separate > system resource limits. > > 2A/ Some code to manage assigments of KSEs to processes and CPUs will be > needed. > > 3/ Kernel structures (proc, sleep queues, run queues?) will need to > change to support KSEs and multiple threads per process being > blocked in the kernel. It seems that struct proc should be analyzed > to classify components as being relevant to the process, KSEs, or > "context being blocked in the kernel". > 4/ Exceptions may be one way to accomplish thread 'signals', as well as a good way to have the thread 'back out' of kernel context if it is abnormally terminated. > Each SUBPROCESS is allocated one or more KERNEL SCHEDULABLE ENTITIES > (KSE's). KSE' may be added to or removed from a SUBPROCESS as needed to > prevent it from involuntarily block (except when it's quantum is exceeded)(*) How does the kernel re-assign an KSE that corresponds to a blocked thread *IF* the user-land scheduler (or some other active thread) wakes it up abnormally (or otherwise). Does the waking thread lose it's quantum? (Note, I think this is a bad idea in most cases, since what often happens with 'blocked' threads is this.) aquire_resource(); do_something(); wake_waiting_thread(); release_resource(); Note, you must wake the waiting thread while holding onto the resource, so if we wake the waiting thread by giving up our KSE, that thread should still be 'blocked' until we give up the critical resource. So, the 'wakeup' in the normal case is really an event that shouldn't be delivered until *after* the current thread loses it's resource. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911120833.BAA17766>