Subject: | |
From: | |
Reply To: | |
Date: | Tue, 3 Jan 1995 20:58:14 -0800 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Hi Chris,
You write:
>For background; the father has MANY son processes hanging off of it. The
>father does a display before and after calling suspend(2) - I get the before
>display but not the after. Not every time, but often enough to be REALLY
>annoying. The son process also displays that it called Activate(0), got a CCE,
>and even calls Getprocinfo to make sure the father is now activated. (Which
>is really confusing, unless the father<->son pointers somehow got misdirected
>to some other process?) or the process' status is updated but its never really
>awakened...?
I had a problem like this a LONG time ago on MPE/(n < 5, can't remember
which version). I solved it with kind of a kludge, but the problem never
came back. The solution involved the use of local RINs, since SUSPEND can
suspend and release a RIN as an atomic operation.
FATHER SON
Create son ------
Lock local RIN
Activate son
Does its thing
Locks local RIN (may suspend until father unlocks)
Suspend+free RIN
Continues, activates father
The RIN guarantees that the son can't activate the father while the
father is still active. LOCRINOWNER might also provide an avenue for some
side benefits; it did in our application.
Checking the state of a process with GETPROCINFO is iffy, since you can't
really have any control over the timing issues. It _may_ be the case that
the son is created at a higher priority than the father, since the process
starts life at the top of its queue and the father may already have sunk
down some. The father gets to finish its time slice, but the next scheduling
round will have the son executing before the father has a chance to suspend,
unless it's suspending via the ACTIVATE call. In fact, there may be a bunch
of processes that get time before the father sees the CPU again.
-- Bruce
|
|
|