From owner-freebsd-arch Sat Aug 25 19:40:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 9964F37B40C for ; Sat, 25 Aug 2001 19:40:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id TAA66162; Sat, 25 Aug 2001 19:48:33 -0700 (PDT) Message-ID: <3B885ED0.9DFCA5B5@elischer.org> Date: Sat, 25 Aug 2001 19:28:32 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "bsd-api-discuss@wasabisystems.com" , Arch@freebsd.org Subject: changes to BSD APIs for THREADS support Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG With both FreeBSD and NetBSD closing in on complete Threads support, there are some items that need to be discussed. For example: How does procfs report a multithreaded process running on several processors? how does PS extract state from the kernel when a process is simultaniously in several states? What does "%cpu" actually indicate? Which wmesg is shown if there are 8 sleeping threads? (does someone have a MACH system that shows these things?) (MacOS X?) Inside the kernel, how are the proiority adjustments calculated when a process might be running and sleeping at the same time? How does ^T decide what thread/proc to report? All this is separate to what syscalls we will be wanting to add to actually give the multithreading libraries access to the new kernel support. On that front FreeBSD is looking at at least 4 new syscalls. I'm going to describe them by function rather than name as the names are not decided: 1/ Add a new kernel schedulable entity (KSE). The first call to this syscall turns on the threading support. To fully utilise an N CPU system you need to do N of these calls. This function will return many times, so its caller must never return or unwind it's stack (until threading is stopped). This system call will return whenever some other system call would block in the kernel. It supplies as an argument, a mailbox in which the reason for returning is to be placed. (and a lot more info). With at least one KSE in operation. All syscalls are asynchronous (Either they return immediatly or an upcall is generated onto the frame stored by #1). 2/ A yield() call which tells the kernel that the user thread scheduler has no present use for the current processor and it may be used by another process. This call does not return. (ever) The KSE is not destroyed, but marked 'idle' within eh kernel. The kernel way activate it (or in fact not idle it) if it DOES have something for it to do (e.g. complete a previously suspended syscall). 3/ A call that can be used by the user thread scheduler to 'unyield' a previously yielded processor. i.e. it could do with it, now, if it's available. (This call will return immediatly but will ALSO come back as an additional return of #1 for a KSE that was previously yielded.) 4/ A call by which a KSE suicides.. It will never return and the #1 frame (upcall frame) associated with this KSE will never be used again and can be freed. If there is only one KSE in action, process operation reverts to un-threaded operation. 5/ It is possible that we may need a call by which the user thread scheduler can 'cancel' the syscall that a particular kernel thread is currently operating on. (particularly if it is waiting). In addition there may be the need for one or two synchronisation primatives though this is not certain. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message