cvs commit: src/sys/sys systm.h src/sys/kern kern_synch.c
dillon at apollo.backplane.com
Tue Oct 25 01:54:09 PDT 2005
:Eirik Nygaard wrote:
:> Make wakeup, tsleep and friends MP-safe.
:Cool. Sad that you had to back it out :/
It's the right idea, it just needs a lot more engineering to conform
to tsleep/wakeup's requirements. These are very low level functions,
used in early boot and in all sorts of other situations (e.g. if malloc
has to block, for example), as well as having to supply certain atomicy
guarentees to avoid sleep/wakeup races... and because of that tsleep
and wakeup are restricted to using only very low level interfaces
to accomplish their tasks. So instead of using LWKT messages they
are going to have to use IPI messages (amoung other things).
:One question I always was wondering about: Why do we have for
:everything and his dog an own lwkt+port? I understand that some threads
:might block (in the future), but I think having a kitchen-sink thread
:per cpu which does non-high-performance tasks (and/or doesn't block)
:could be a good idea. Or am I on the wrong track? Do people understand me?
You mean why is there a LWKT message port embedded in the thread
structure? Well, because that's what the Amiga had :-). Actually it
isn't a perfect fit and I am considering removing the embedded message
port in each thread, but there is still a good possibility that we can
make use of the port to handle things that must be executed in the
context of the thread but must not be executed preemptively. e.g.
signal delivery, /proc stops/starts and other control operations, and
so on and so forth.
One thing I do know is that we really have to consolidate process related
events, if only to reduce the overhead of checking for ten different
things every time a process context switches into or out of the kernel.
A per-thread message port would seem to be the right idea.
<dillon at xxxxxxxxxxxxx>
More information about the Commits