Date: Sat, 25 Aug 2001 19:28:32 -0700 From: Julian Elischer <julian@elischer.org> To: "bsd-api-discuss@wasabisystems.com" <bsd-api-discuss@wasabisystems.com>, Arch@freebsd.org Subject: changes to BSD APIs for THREADS support Message-ID: <3B885ED0.9DFCA5B5@elischer.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B885ED0.9DFCA5B5>