HP3000-L Archives

January 1995, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bruce Toback <[log in to unmask]>
Reply To:
Bruce Toback <[log in to unmask]>
Date:
Tue, 3 Jan 1995 20:58:14 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (41 lines)
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

ATOM RSS1 RSS2