Re: cvs commit: src/sys/sys systm.h src/sys/kern kern_synch.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:Eirik Nygaard wrote:
:>   Log:
:>   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?
:
:cheers
:   simon

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>