# Copyright (c) 1993 Xerox Corporation. All rights reserved. # # MPNotes.txt # Questions: 1. EnableHostSigs/DisableHostSigs must work per lwp! 2. The PrepareForSpawn stuff has to be examined ... maybe it should be removed altogether, since it's so complex! 3. Leaving the running proc on the run queue is a bad idea if there are multiple lwp's -- DONE -- 4. RunExclusive will have mp memory model problems?! Clearly doCheckIO is for all vps? doCheckTimeout ??? and doCheckChildren is problematic -- I'm becoming more convinced we shouldn't try to emulate fork/spawn. Current implementation has: sys cr sec nest (per thread) deferredAction per thread? an accelerator, says there's something interesting to do on sys cr sec exit mustCheckSigs per thread, indicates the thread needs to get signals by calling AcceptPendingSigs (in cr sec) and then PCR_ThPvt_HandleAcceptedSigs (outside cr sec). PCR_ThGlue_doCollectSigs global used to tell the thread switcher that it's time to collect host sigs. PCR_SigPvtImpl_sigsRecvd[], PCR_SigPvtImpl_postCnt the host signals received. To make this work with multiple lwp's we'll need to do mutual exclusion among the lwp host sig handlers that are storing into the alternate word of sigsRecvd. This shouldn't be too hard. PCR_SigPvtImpl_externalInterrupts list of external interrupts that have arrived at the process but not yet used by the PPCR external interrupt mechanism. Actually it may be okay that there's a global one of these, since it's only manipulated from sys critical section. For the revised system: Sys critical section: - mutual exclusion - nestable - thread signal handlers aren't invoked - no preemption? This is irrelevant in MP ... but preemption per se would require entering a sys critical section, so ... - voluntary thread switching? This could be arranged, since the meta lock would be acquired around a switch, and the switchee's nesting count would control release of it ... Lib critical section: - mutual exclusion - nestable - thread signal handlers aren't invoked ? Maybe they could be, if unwind protection is done carefully in the library shim implementation. Think about this. - preemption is okay. - voluntary thread switching is of course okay. Does this have anything to do with GC? I think vd implementation takes care of that ... Does this have anything to do with errno? Would be nice if it didn't! n.b. can't do EnterLib while in a sys critical section! If I ignore the Lib critical section part and just concentrate on sys: Implementation: - sys cr sec nest count is per-thread - gotKicked is per lwp, set if the lwp receives a (host) signal while in a sys critical section, maybe other reasons ???? - PCR_ThGlue_doCollectSigs is global, set if there are any unprocessed host sigs to be picked up. The host signal handler(s) have to do mutual exclusion (using lwp mutex stuff, on solaris) around the PCR_SigPvtImpl_sigsRecvd[] repository; the alternating-location strategy currently being used will work okay between the thread level and the handlers. - mustCheckThreadSigs is per thread, set if there might be signals available for the thread. This is set by code in sys critical sections that sends signals; (???not needed for traps, because the thread switcher should notice???) - thread switch: EnterSys() if( PCR_ThGlue_doCollectSigs ) { PCR_SigPvtImpl_CollectSigs(&myTraps) PCR_ThPvtImpl_DistributeSigs(&myTraps) } do { gotKicked[thislwp] := false; do computation to determine next thread do coroutine jump to next thread /* when I get back ... */ } while( gotKicked[thislwp] ); at some point somebody does exitsys ... <<< NOTES FOR REMOVING RUNNING THREAD FROM READY QUEUE: NOTE: run exclusive is going to have mp memory model problems! PCR_ThPvt_RemSelfRunQ() is a pretty good indication ... called in 4 places. Active thread slot data entries are in a circular list headed by PCR_ThPvtImpl_active. A single field tsd_next puts slotdata entries on either ML/CV or run lists; the switcher can test whether curr thread is on a list and if not put it on the appropriate run list. This means inactive tsd's just go on another thread queue, and aren't linked together by overloading the active slot data links. PCR_ThPvt_MoveSelfRunQ XXX !!! Do CheckIO, checkTimeout, checkChildren possibly switch? If so, they'll break horribly if switcher is called with curr thread on a wait queue? maybe not -- think about this. No, I think this is okay. -- this is DONE, seems okay -- >>> ================================ two actions require rescheduling: blocking, and making runnable. rescheduling may be appropriate for a different processor from the one I'm running. directed yield is still a reasonable concept, and affects *my* processor ... Suppose there's a GblSched() proc: EnterSys() for(;;) { find next most deserving runnable thread if its priority <= that of lowest prio vp break n++ } send RESCHED to the n lowest pri vp's Note: when a signal is sent to a thread, it's either a trap (in which case the thread is guaranteed to be on the stack below the host sig handler, and will look for it immediately) or was sent by another thread (in which case we need to force that thread to RESCHED?!???) Suppose we say every host signal results in a resched of its processor. The above GblSched() proc is still useful; we reserve a host sig for RESCHED. If we have a VM-based virtual dirty implementation, then SEGV may not involve a resched? Probably this is viable only if protection state is shared by all lwp's. When a host sig arrives: - A non-trap signal is put somewhere that the host sigs implementation can get at it ... - if interrupted thread was in critical section, the sig had better not be a trap or we're broken. - if interrupted thread was *not* in critical section, we're going to switch out of the trap handler. It must do entersys, arrange for the host traps (after translation) to be delivered to the current thread, then switch. Must arrange to have host sigs enabled right on threads switched to and from