Dit is, zoals ik me de natuurlijke dood van een programma voorstelde. In verband met schijndood en de gewelddadige dood (zie onder) komt er nog wel wat bij.
3. De operateur heeft de mogelijkheid (waarvoor moge de hemel weten) om een programma schijndood te verklaren. Het moet dan op een zacht pitje zitten wachten, totdat het weer, via de console, wordt gewekt.De complicatie bij schijndood is, dat het programma dat zachte pitje bij voorkeur wel plaatst op een onschuldig punt. Wij hadden zo gedacht "niet in een rode sectie". Als een programma wit en uitvoerbaar is, dan kan het commando tot schijndood meteen verwezenlijkt worden: men boekt het als wachtend op een voor dit doel in elke PM voorkomende seinpaal. Anders moeten we alleen het verzoek tot schijndood boeken (weer een toestand, waarin het commando "val schijndood" als NA behandeld zou kunnen worden).
Deze blokkering van schijndood moet achterwege blijven, als de PM rood is (hij moet nog doorwerken) en is niet lekker codeerbaar, als de PM al op een andere seinpaal staat te wachten. De uitgestelde schijndoodheid moet effectief worden bij de witmakende V-operatie en de voltooide P-operatie. (Opmerking van Piet: de schijndood hoeft pas effectief te worden als je dreigt de controle aan een wit proces metterdaad te gunnen. Dit geldt ongeacht de reden tot uitstel en zou tot compactere codering aanleiding kunnen geven.)
De wekoperatie is nu makkelijk. Als de schijndood gevraagd, maar nog niet gerealiseerd is, kan worden volstaan de notitie weg te nemen. Als de aanvraag niet hangt, moet de schijndood gerealiseerd zijn (anders NA) en de message interpreter kan op de daartoe strekkende seinpaal een V-operatie uitvoeren. (Let wel, dat het veilig lijkt om voor de schijndood een specifieke seinpaal per PM in te voeren !)
Het grote probleem van de gewelddadige dood is, dat we dit programma moeten beÎindigen, dwz. er een punt aan moeten draaien, zodat het toch nog well-behaved blijft. Een eerste vereiste is, dat het in elk geval zover doorgaat (zo nodig), dat ook de toestand "schijndood" zou mogen ingaan. Dit geeft ons een nieuw criterium om vast te stellen, waar roodheid begint en waar roodheid moet ophouden: buiten roodheid moet de PM in een hanteerbare toestand achterblijven. Nadat we nu straks hebben laten zien, wat we ons bij dat hanteren voorstellen, moeten we de stukken PM-programma, waarin roodheid voorkomt en die we inmiddels gemaakt hebben, in dit licht nog eens duchtig nakijken.
Er is een communicatieapparaat, dat hier wat roet in het eten doet, en dat is de trommel. Ik wil een programma liever niet vermoorden, als het nog op een seinpaal staat te wachten, in het bijzonder niet, wanneer het aan de segment controller een segment gevraagd heeft. Als we af kunnen spreken, dat sterven niet begint, zolang de PM nog op een seinpaal wacht, dan kunnen we dit als volgt spelen (NB. Het aanvragen van een segment aan de segment controller gaat buiten alle roodheid om: het kan in roodheid, het kan in witheid). Bij de opdracht aan de segment controller kan de PM een boolean "Aanvraag Segment" true zetten.
De structuur in de PM wordt dan
AS := true
aanvrage van segment
V(SCS)
AS := false; P(eigen segment seinpaal)
De laatste twee statements staan op een regel, om heel nadrukkelijk af te spreken, dat ze in doofheid na elkaar gebeuren. Nu spreken we af, dat de initialisering van de zelfmoordriten niet plaats kan vinden, als AS. Hiermee bereiken we, dat de aangevraagde pagina's er zijn, voordat ze wellicht vernietigd zijn. (Ik schreef pagina's, ik bedoelde segmenten.)
Zo te zien, kunnen we met 1 variabele "killvar" al een heleboel doen. Tentatief zou ik deze de volgende waarden met de volgende betekenis willen geven (De op pag.0 gesuggereerde codering van X "runnummer = 0" kan dan vervallen.)
| killvar = 0 | De PM is leeg |
| killvar = 1 | De PM is bezig met een programma, dat volslagen levend is |
| killvar = 2 | Er is aanvrage tot schijndood |
| killvar = 3 | Het programma is schijndood (hangt op de seinpaal killsem) |
| killvar = 4 | Er is aanvrage tot zelfmoord |
| killvar = 5 | Het programma is tot de zelfmoordriten overgegaan. |
(Of de boolean AS hier ook in gecodeerd moet worden, bv. door killvar = 8 is voor mij nog een open vraag.)
Ik stel me nu op het standpunt, dat het agens, dat de zelfmoordopdracht geeft, hiervan via de consoleteleprinter melding maakt, maar dat we de PM (of liever: het er in zittende programma) niet de gelegenheid geven, nog een brief aan vrienden en bekenden ten afscheid te schrijven, dus geen rapportering over de status, warin het programma zich bevond, toen tot de zelfmoordriten werd overgegaan. (Hoogstens voeren we nog in
| killvar = 6 | Het programma is op eigen initiatief tot de zelfmoordriten overgegaan, in tegenstelling tot killvar = 5. Op de laatste printerform kan dan nog een kreet komen te staan "ik heb mezelf beeindigd", dan wel "ik ben er afgetrapt".) |
Ik hoopte, dat de overgang tot de zelfmoordriten geeffectueerd zou kunnen worden door in de status van het onderbroken programma zo te knoeien, dat zo ongeveer met het mechanisme van de General Goto de besturing springt naar het punt in het PM-blok, waar de PM de stromen gaat afmaken. Dit is niet genoeg, want er kunnen vanwege de SIS twee programmasegmenten heilig zijn - en de general goto ontheiligt er maar 1tje, als de moord plaatsvindt wanneer een arraysegment heilig is aangevraagd, dan zitten we daar ook nog mee. (De moord wordt wel uitgesteld, totdat dit segment gearriveerd is). Ik kan me voorstellen, dat een en ander bij het heilig aanvragen van arraysegmenten een extra notitie vergt en dat de overgang tot de zelfmoordriten zo min mogelijk door de coordinator en zoveel mogelijk door de PM zelf gebeurt. Het wegwerken van een stukje SIS (ontheiliging en zo) is nl. een handeling, die bij de dynamische fout onder auspicien van de PM zelf zal gebeuren.
Na ampele overwegingen zijn we tot de conclusie gekomen, dat de reactie op een dynamische fout een zuivere PM-aangelegenheid is. Ik stel me zo voor, dat deze alleen tijdens killvar = 1 zal kunnen voorkomen (in rode stukken wil ik helemaal niet zulke griezelige dingen kunnen doen). De PM zal dan de stapel moeten afbreken totaan de eerste Working Space Pointer; als de fout in een SIS optreedt, dan moet hij dit door stapelinspectie ontdekken, als er nog een arraysegment heilig is, dan weet het foutendetecterende mechanisme dat, en kan dat arraysegment ontheiligd worden. Is de stapel teruggebracht tot het eerste niveau, waarop SE1 aangeroepen kan worden, dan zal dat moeten gebeuren om een aanroep van de procedure ALARM te kunnen simuleren. Met de sprong daarnaar toe wordt de laatste programmapagina ontheiligd, ALARM kan onder zich de stapel zoveel inspecteren als hij wil en kan tenslotte springen naar het punt in het PM-blok, waar we na programmabeÎindiging terecht komen.
De microscopie van het mieren aan de status onder in de HAM-kamer en het toespelen naar een tussengeschoven systementry is een spelletje, dat me wel boeit; ik beschik zelf niet over de kennis om direct te zien, hoe dit moet, ik dacht wel, dat het kon en wil er graag over helpen denken.
|
EWD.
|