NL1025169C2 - Procesmobiliteitsprotocol. - Google Patents

Description

Procesmoblllteitsprotocol

Deze uitvinding heeft betrekking op technieken voor mobiele verwerking en kan met name toegepast worden op real-time systemen.

5 Mobiele verwerking houdt in: de migratie van processen van een bronknooppunt (bijvoorbeeld een machine) naar een doelknooppunt De migratie vindt niet werkelijk plaats, maar wordt nagebootst: een nieuw proces wordt gecreëerd op het doelknooppunt en, nadat de context van het proces op het bronknooppunt is gekopieerd, wordt het proces op het bronknooppunt 10 afgebroken. Het netto effect is echter dat de verwerking van een hoeveelheid data is verplaatst van bron- naar doelknooppunt.

Een proces dat wordt uitgevoerd op een knooppunt wordt een "incarnatie" genoemd. Het proces op het bronknooppunt is de "oude 15 incarnatie". Het proces op het doelknooppunt heet de "nieuwe incarnatie".

De vereisten voor procesmigratie zijn dat de huidige status van het proces op het bronknooppunt overgezet kan worden naar het doelknooppunt, zodanig dat de nieuwe incarnatie op het doelknooppunt kan doorgaan met 20 verwerken. Dit betekent dat niet alleen het proces moet worden gekopieerd op het doelknooppunt, maar dat ook een momentopname van de huidige inhoud ervan moet worden geïnstalleerd. Vervólgens moet de nieuwe incarnatie van het proces in dezelfde status gebracht worden als waarin de oude incarnatie zich bevond. Tenslotte moet de oude incarnatie worden 25 afgebroken, terwijl de nieuwe incarnatie aangezet wordt om door te gaan vanaf het punt waar de oude incarnatie gestopt was.

Een besturingssysteem (OS) houdt de status en context bij van elk proces dat in uitvoering is en voert scheduling-taken uit. Tot de taken van 30 een OS behoort echter niet het verplaatsen van een proces van knooppunt naar knooppunt. Immers, OS-en zijn hardware-georiënteerd. De notatie, met name, van context en status verschilt per OS. OS-en van hetzelfde merk maar van een verschillende release, of zelfs OS-en van hetzelfde merk en van dezelfde release maar bedoeld voor verschillende hardwaresystemen '25169 2 kunnen essentiële verschillen vertonen. Met andere woorden, OS-en ontberen het vermogen tot samenwerking en code-overdracht dat nodig is voor het implementeren van mobiele verwerking tussen verschillende systemen.

5

Conventionele systemen voor mobiele verwerking, zoals die welke toegepast worden in agent-based systemen, hebben een zogenaamde virtuele machine (VM) nodig voor het implementeren van procesmobiliteit. De VM is een vertaler, die een instructieset levert, een set registers, een 10 collected-garbage heap en een voor het proces bruikbaar geheugen. De VM interpreteert de code van de processen en beheert zodoende de status en context voor deze processen. De VM regelt tevens de uitvoering van de processen. Het is betrekkelijk gemakkelijk om de status en context van een proces in dergelijke gevallen te bevriezen en te vervoeren. Met andere 15 woorden, het gebruik van virtuele machines maakt procesmobiliteit mogelijk tussen verschillende OS-en.

Er zijn echter grote nadelen. Met name is het dienstenpakket van een VM beperkt in vergelijking met de diensten die de OS-en zelf leveren. De 20 processen, met andere woorden, zijn gebonden aan de diensten die deVM biedt. VM's voorzien bijvoorbeeld slechts in één specifieke vorm van gedeeld geheugen of kennen helemaal geen gedeeld geheugen. Aangezien de VM's gebruik maken van een abstractielaag, voeren deze bovendien hun eigen scheduling, threading enz. uit. Daarom worden scheduling, threading en 25 real-time gedrag op procesniveau niet ondersteund. Tenslotte wordt de interprocescommunicatie (IPC) gewoonlijk niet ondersteund door de VM's.

Een ander nadeel is dat het gebruik van een VM vereist dat processen er op afgestemd zijn (bijvoorbeeld, JAVA VM, JADE platform...).

30 Daardoor is de mobiliteit beperkt tot processen op de VM en andere (tot samenwerken in staat zijnde) VM's op verschillende knooppunten.

Er zijn nog meer nadelen: - een VM is niet geschikt voor tijd-en veiligheidskritische systemen, 35 - een VM is niet geschikt voor real-time systemen, 025169 ' 3 - de voornaamste resources van een knooppunt zijn moeilijk vanuit de VM te bereiken.

Zoals blijkt uit de hieronder en in de conclusies beschreven 5 eigenschappen, is de uitvinding bedoeld om de bovengenoemde nadelen te elimineren. Met name is de uitvinding erop gericht om een proces veilig te verplaatsen tussen verschillende knooppunten (bijvoorbeeld, verschillende machines met verschillende OS-en), zonder de beperkingen van een VM.

10 Om dit doel te bereiken en tevens andere, hierna toe te lichten voordelen te realiseren, voorziet de uitvinding speciaal in een werkwijze voor het bevorderen van de procesmobiliteit. De uitvinding wordt geïmplementeerd in portaalprocessen, zogenaamde gateways. Volgens een kenmerk van de uitvinding transporteren de gateways de mobiele· 15 procescontext (de oude incarnatie) van het ene naar het nadere knooppunt. Daartoe zorgen de proces-gateways voor het opstarten, op verschillende knooppunten, van equivalente processen die gemakkelijk toegang kunnen krijgen tot de resources van het knooppunt en waarvan de context is afgestemd op de hardware en het OS van het knooppunt. De proces-20 gateways zijn betrokken bij de uitwisseling van de noodzakelijke contextinformatie, om een equivalente context te reconstrueren voor de nieuwe incarnatie.

Meer in het bijzonder is het een doel van de uitvinding om een 25 werkwijze te realiseren voor het verplaatsen van een proces van een bronknooppunt naar een doelknooppunt, waarbij: - een oude incarnatie van het proces (3), die in uitvoering is op het bronknooppunt, de eigen context in een frame (13) opslaat; - een nieuwe incarnatie van het proces (4) gestart wordt op het 30 doelknooppunt, welke nieuwe incarnatie (4) de status "gereed" heeft; - een rechtstreekse communicatie (21) tot stand wordt gebracht tussen de oude incarnatie (3) en de nieuwe incarnatie (4) van het proces, waarin de opgeslagen context verzonden wordt van de oude incarnatie naar de nieuwe incarnatie; 251 69 4 - de nieuwe incarnatie met verwerken begint (24), gebruikmakend van de ontvangen context.

De voornaamste voordelen van de uitvinding zijn dat de processen 5 gemakkelijk toegang kunnen krijgen tot systeem-resources en andere processen, dat de procesmobiliteitswerkwijze kan voldoen aan de veiligheids- en beschermings-constraints en dat samenwerking mogeiijk is in een hybride netwerk.

10 De werkwijze volgens de uitvinding kan worden toegepast om de j werkbelasting in een systeem evenwichtig te houden. Processen brengen immers een werkbelasting met zich mee op het knooppunt waarop zij worden uitgevoerd en te veel belasting op een knooppunt kan de uitvoering van de processen hinderen, met name wanneer er sprake is van tijdkritische i 15 processen. Mobiele verwerking is een manier om de belasting in balans te houden, door processen van overbelaste knooppunten over te brengen naar knooppunten met voldoende capaciteit en lage belasting.

In een gunstige uitvoeringsvorm slaat de oude incarnatie de eigen 20 context regelmatig op, op vooraf bepaalde synchronisatiepunten, welke context ingepakt wordt in een frame na ontvangst van een signaal van een bron-gateway.

In een andere gunstige uitvoeringsvorm bevat de context de 25 inhoud van het geheugen en de status van het proces.

in een andere gunstige uitvoeringsvorm wordt de nieuwe incarnatie gestart na ontvangst van een signaal van de doel-gateway.

30 In een andere gunstige uitvoeringsvorm wordt het signaal voor de start van de nieuwe incarnatie verzonden na ontvangst van een signaal van de bron-gateway.

251 69 5

In een andere gunstige uitvoeringsvorm wordt de rechtstreekse communicatie tot stand gebracht door middel van een Socket, het poortnummer waarvan: - door de nieuwe incarnatie gezonden wordt naar de doel-gateway, en 5 vervolgens - door de doel-gateway gezonden wordt naar de bron-gateway, en vervolgens - door de bron-gateway gezonden wordt naar de oude incarnatie.

10 In een andere gunstige uitvoeringsvorm, zijn de oude en nieuwe incarnaties multi-threaded processen.

In een andere gunstige uitvoeringsvorm slaat elke thread van de oude incarnatie de eigen context op, waarbij een van deze threads een 15 hoofd-thread is en de opgeslagen contexten door de hoofd-thread ingepakt worden in één enkel frame.

De uitvinding zal nu worden beschreven op een meer gedetailleerde wijze, aan de hand van een speciale praktijkuftvoeringsvorm 20 als voorbeeld. In deze beschrijving zal worden verwezen naar de aangehechte Afbeeldingen, waarvan: - Afbeelding 1 een tijddiagram is van een voorbeeld van de implementatie van een procesmobiliteitswerkwijze volgens de uitvinding; - Afbeeldingen 2a en 2d tijddiagrammen zijn van een voorbeeld van een 25 implementatie van een multi-threaded variatie van de werkwijze.

Beschouw eerst Afbeelding 1. Volgens de uitvinding worden synchronisatiepunten toegevoegd aan de mobiele processen. Een synchronisatiepunt 5 is een stap waarin het proces (oude incarnatie) 30 informatie opslaat, zoals de inhoud van zijn geheugen en zijn status. Deze informatie is vergelijkbaar met de informatie die opgeslagen wordt door een debugger die een core dump file genereert.

Om de procesmobiliteitswerkwijze uit te voeren, zendt het 35 gateway-proces 1, dat in uitvoering is op het bronknooppunt een "verplaats" 125169 6 signaal 6 naar het proces 3 (oude incarnatie) dat op diens knooppunt in uitvoering is. Voor de duidelijkheid wordt het gateway-proces 1 dat in uitvoering is op het bronknooppunt aangeduid als de bron-gateway.

5 De bron-gateway 1 zendt ook een "start proces" signaal 8 naar het gateway-proces 2 dat op het doelknooppunt in uitvoering is. Voor de duidelijkheid wordt het gateway-proces 2 dat in uitvoering is op het doelknooppunt aangeduid als de doel-gateway. Het "verplaats" signaal 6 en het "start proces” signaal 8 kunnen bijvoorbeeld worden gerealiseerd door 10 middel van onderbrekingen. Het "verplaats" signaal 6 kan worden verzonden na of voor het "start proces" signaal 8. Het “verplaats" signaal 6 kan een Interrupt zijn. Het “start proces” signaal 8 zal met grote waarschijnlijkheid in de vorm van een bericht worden gegoten, dat specifieke informatie bevat (pad, argumenten, omgeving) van het te starten proces.

15

Het "verplaats" signaal 6 initieert stappen 7,13 en 14, die uitgevoerd worden door de oude incarnatie om een frame te construeren. In concreto, wanneer de oude incarnatie 3 het "verplaats" signaal 6 ontvangt, komt deze in een wachtstatus 7. Alle bewerkingen uitgevoerd tussen het 20 laatste synchronisatiepunt 5 en de ontvangst van het "verplaats” signaal 7 gaan verloren. Vervolgens voert de oude incarnatie een stap 13 uit, het zogenaamde inpakken van de context, waarbij deze een frame construeert dat de informatie bevat die op het laatste synchronisatiepunt werd opgeslagen. Aan het eind van het context-inpakken 13, zendt het proces een 25 "einde" signaal 14 naar de bron-gateway 1, om aan te geven dat het klaar is met het inpakken 13 van de context. Dit "einde" signaal wordt vervolgens door de bron-gateway 1 doorgegeven aan de doel-gateway 2 door middel van een "hold" signaal 15. Volgens een andere implementatie (niet getoond), wordt het "hoid” signaal 15 rechtstreeks door de oude incarnatie verzonden 30 naar de doel-gateway.

Het "start proces" signaal 8 is een verzoek om een identiek proces 4 te starten op het doelknooppunt. Dit nieuwe proces 4 (nieuwe incarnatie) start echter bij nul. De doel-gateway 2 kan de nieuwe incarnatie storten (9) 35 door bijvoorbeeld gebruik te maken van de Fork/Exec instructie in Unix. Als )25169 - 7 de nieuwe incarnatie start, voert deze een registratie 10 uit via het OS. Deze registratie vertelt het OS dat het nieuwe proces er een is van het nieuwe-incarnatietype. Met andere woorden, de nieuwe incarnatie meldt zich als mobiel. De registratie houdt een lokale interactie in met de doei- (lokale) 5 gateway 2.

De registratie 10 van de nieuwe incarnatie omvat bijvoorbeeld de volgende stappen: 1. Installatie van inpakfüncties.

10 2. Installatie van herstelfuncties.

3. Installatie van uitpakfuncties.

De inpakfüncties zijn de functies die gebruikt worden voor het inpakken 13 van de context.

15

De herstelfuncties zijn ingangspunten die het proces in staat stellen de uitvoering op te pakken vanuit een gegeven processtatus. Deze gegeven processtatus is de op een voorbeschreven synchronisatiepunt (bijvoorbeeld synchronisatiepunt 5) opgeslagen processtatus.

20

De uitpakfuncties voeren de omgekeerde handeling uit van de inpakfüncties. Uit een ingepakte context construeren deze een bruikbare proceslooptijdcontext. De uitpakfuncties worden gebruikt indien het proces een nieuwe incarnatie blijkt te zijn.

25

Voor het uitvoeren van de installatie van de inpak/herstel/uitpakfuncties worden de locaties van de functies voor het proces opgeslagen in, bijvoorbeeld, een sprongtabel.

30 Volgens een voorkeursuitvoeringsvorm zijn de tijdens de registratiestap 10 geïnstalleerde functies handlers. Een handler is een functie die door het OS bij specifieke gebeurtenissen wordt opgeroepen, zoals een uitzondering X of een signaal Y. Indien de uitzondering X zich voordoet of het signaal Y wordt naar het proces gezonden, onderbreekt het OS onmiddellijk 35 de uitvoering van het proces en roept de geëigende handler op. De installatie 125169 8 van een handler gebeurt gewoonlijk in de vorm van een systeemoproep, die de default bandier van het OS overschrijft.

Doordat deze uitvoeringsvorm voor de interprocescommunicatie 5 en -synchronisatie gebruikt maakt van laag-niveau interrupts (signalen), kan de uitvinding real-time scheduling-kwesties hanteren. Deze laag-niveau interrupts kunnen alleen worden gegenereerd op het niveau van een host (d.w.z., op het lokale knooppunt) en niet op het niveau van een netwerk.

10 In sommige OS-en zijn handlers "vluchtig”, hetgeen betekent dat het OS de default handler opnieuw installeert voorafgaand aan het oproepen van de handler. Dit kan ongedaan gemaakt worden door het herinstalleren van een door gebruiker gedefinieerde handler voor, bijvoorbeeld, signaal Y bij het afsluiten van de handler-functie voor signaal Y.

15

Tijdens de registratie 10 kan de nieuwe incarnatie ook een bericht zenden aan de doel-gateway, om die gateway te informeren dat het proces mobiel is. Na ontvangst van het bericht met de informatie dat het proces mobiel is, zendt de lokale gateway een antwoord. Het antwoord kan 20 een bevestiging zijn, of een token die het proces aanmerkt als een nieuwe incarnatie. Volgens een andere uitvoeringsvorm kan het proces het feit dat er sprake is van een nieuwe incarnatie afleiden uit een vlag in de context ervan, die opgezet is tijdens de start 9 actie. Met andere woorden, het proces ontvangt deze informatie niet van de gateway: in plaats daarvan controleert 25 het zijn context.

Ongeacht het algoritme zal het proces, aan het eind van de registratie 10, weten of er wel of niet sprake Is van een nieuwe incarnatie van een migrerend proces (geïdentificeerd door een bevestiging van de gateway 30 of een vlag in zijn context). Indien een proces geen nieuwe incarnatie is, start het een normale uitvoering. Indien het proces een nieuwe incarnatie blijkt te zijn, gaat het naar een voorbereidingsstap 11.

Tijdens de voorbereidingsstap 11 bereidt de nieuwe incarnatie 4 35 zich voor op het ontvangen van de ingepakte context (frame gegenereerd 151 69 9 door de oude incarnatie). Onderdeel van de voorbereidingsstap 11 is, dat de nieuwe incarnatie het OS om een socket (communicatiemiddel) verzoekt.

De voorbereidingsstap 11 omvat bijvoorbeeld de volgende 5 stappen: 1. De nieuwe incarnatie verzoekt om een socket, gebruikmakend van door het OS beschikbaar gestelde systeemoproepen.

2. Het poortnummer van de toegewezen socket wordt door de nieuwe incarnatie in een bericht aan de doel-gateway gezonden.

10 3. De nieuwe incarnatie gaat naar een houdlus, wacht op een "luister*’ signaal 16 en gaat dan luisteren via de toegewezen socket.

Volgens een andere uitvoeringsvorm gaat de nieuwe incarnatie niet naar een houdlus, maar gaat meteen luisteren na het bericht 15 (poortnummer) naar de doel-gateway gezonden te hebben.

Wanneer de nieuwe incarnatie klaar is met de registratie 10 en voorbereidingsstap 11, zendt deze een "hold" signaal 12 terug naar de doel-gateway 2. Dit "hold" signaal 12 geeft aan dat de nieuwe incarnatie de status 20 "gereed" heeft en wacht op het tot stand brengen van een communicatie. Dit "hold” signaal 12 kan het adres bevatten van de door de nieuwe incarnatie verlangde socket.

De doel-gateway 2 wacht op beide "hold” signalen 12 en 15. Als 25 beide signalen zijn ontvangen, zendt de doel-gateway 2 het "luister** signaal 16 naar de nieuwe incarnatie. De nieuwe incarnatie is dan in een luistermodus 17. De doel-gateway 2 zendt ook een "start uitzending" signaal 18 naar de the bron-gateway. Het "start uitzending” signaal 18 kan het adres bevatten van de door de nieuwe incarnatie verlangde socket. Het "start 30 uitzending” signaal 18 wordt door de bron-gateway 1 doorgegeven aan de oude incarnatie door middel van een "zend" signaal 19. Dit "zend" signaal 19 kan worden gebruikt om het adres van de socket te verzenden.

Volgens een voorkeursuitvoeringsvorm, komt de oude incarnatie, 35 na beëindiging van het contextinpakken 13, in een houdlus, waarin deze de 0251 69 10 bron-gateway blijft verzoeken om het poortnummer van de toegewezen socket. Elk verzoek wordt door de bron-gateway doorgegeven aan de doel-gateway. Wanneer de nieuwe incarnatie erin geslaagd is het verzoek om een socket ingewilligd te krijgen en dit aan de doel-gateway te berichten, zal de 5 doel-gateway reageren door het juiste poortnummer naar de bron-gateway te verzenden. Op zijn beurt zal de bron-gateway reageren op het verzoek van de oude incarnatie door dit poortnummer af te geven. Het poortnummer kan opgenomen zijn in het “zend” signaal 19. Het "zend" signaal kan ook het poortnummer zelf zijn. Indien de nieuwe incarnatie nog niet klaar is met het 10 vragen om een socket en het in kennis stellen van de doel-gateway, reageert de doel-gateway met een speciaal “nog niet klaar" antwoord aan de bron-gateway, die hetzelfde antwoord zal geven aan de oude incarnatie. Dit “nog niet klaar” antwoord initieert weer een iteratie van de houdlus van de oude incarnatie.

15

Na het ontvangen van het poortnummer is de oude incarnatie 3 in een zendmodus en gebruikt de door de nieuwe incarnatie gevraagde socket om een rechtstreekse communicatie 21 tot stand te brengen met de nieuwe incarnatie. Tijdens deze communicatie 21 wordt de ingepakte context 20 verzonden (geformatteerde transmissie). Wanneer de context verzonden is, zendt de nieuwe incarnatie een "klaar" signaal 22 naarde doel-gateway.

Een proprietary bibliotheek kan bijvoorbeeld de middelen verschaffen voor het inpakken van de context 13 en het zenden en 25 ontvangen van de ingepakte context 21. Het formaat is niet van belang.

Na ontvangst van het "klaar” signaal 22, zendt de doel-gateway een "ga door” signaal 23 aan de nieuwe incarnatie en een "klaar" signaal 25 naar de oude incarnatie. Het "ga door” signaal 23 maakt dat de nieuwe 30 incarnatie begint met verwerken, gebruikmakend van de in de ingepakte context gezonden informatie. Met andere woorden, de nieuwe incarnatie hervat het bewerken op het laatste synchronisatiepunt 7 van de oude incarnatie.

251 69 11

De nieuwe incarnatie heeft synchronisatiepunten, zoals punt 28, die deze in staat stellen zich weer naar een ander knooppunt te verplaatsen door middel van dezelfde werkwijze.

5 Het "klaar" signaal 25 wordt door de bron-gateway doorgegeven aan de oude incarnatie door middel van een "breek af signaal 26. Dit "breek af signaal stopt de uitvoering 27 van de oude incarnatie. Het "breek af signaal initieert een beëindigfunctie in de oude incarnatie, waardoor deze op een beheerste manier een aantal deregistratie-activiteiten kan uitvoeren, een 10 aantal systeem-resources vrijgeven enz.

Volgens een andere uitvoeringsvorm kan de oude incarnatie worden gestopt door een afbreeksignaal van het OS. Een beheerst soort beëindiging (d.w.z., met een beëindigfunctie) verdient de voorkeur boven een 15 dergelijke geforceerde beëindiging. De oude incarnatie kan immers nog steeds verbonden zijn met een aantal soortgelijke elementen in de gedistribueerde omgeving, kan in het bezit zijn van een aantal handles enz. aangezien zij onderbroken was midden in de werkzaamheden (op het laatste synchronisatiepunt voor het "verplaats” signaal 6).

20

Verwezen wordt nu naar Afbeelding 2a, waarin de in relatie tot Afbeelding 1 beschreven werkwijze is aangepast aan een multi-threaded proces. In dit voorbeeld van een implementatie, meldt elke thread zich afzonderlijk en pakt elke thread zijn eigen context in en uit.

25

De bron-gateway zendt "verplaats" signaal 6 naar de hoofd-thread 3a. Wanneer de hoofd-thread 3a het "verplaats” signaal 6 ontvangt, onderbreekt deze de sub-threads 3b en 3c en onderbreekt tevens zichzelf. Alle threads zijn dan in een wachtstatus, hetgeen wil zeggen dat alle 30 verwervingsactiviteiten stilgelegd zijn. Elke thread 3a, 3b, 3c van de oude incarnatie heeft een eigen synchronisatiepunt 5a, 5b, 5c. Alle verwerkingen die uitgevoerd worden tussen elk synchronisatiepunt en de ontvangst van het "verplaats" signaal 6 gaan verloren.

ï 51 69 12

Vervolgens pakt elke thread de eigen context in. In concreto pakt elke sub-thread 3b, 3c zijn eigen lokale context 13b, 13c in en sluit af (stopt met uitvoeren) 27b, 27c. De hoofd-thread pakt zijn eigen lokale context 13a in en pakt de globale context van de oude incarnatie in. De globale context 5 kan bijvoorbeeld een sequentie zijn van de ingepakte contexten 13b, 13c, 13a, zoals geïllustreerd in Afbeelding 2a. Wanneer het inpakken van de (globale) context voltooid is, zendt de hoofd-thread een "einde" signaal 14 naar de bron-gateway, om aan te geven dat het inpakken van de globale context klaar is. Zoals eerder beschreven wordt vervolgens het "einde" 10 signaal doorgegeven aan de doel-gateway door middel van een "hold” signaal 15.

Volgens een voorkeursuitvoeringsvorm zijn er twee typen uitpakfunctie: een hoofd-thread uitpakfunctie en een sub-thread uitpakfunctie. 15 De hoofd-thread uitpakfunctie wordt gebruikt om de context voor de hoofd-thread uit te pakken (die mogelijk in sub-threads uitvorkt; een enkel-threaded proces heeft alleen een hoofd-thread). De sub-thread uitpakfunctie pakt de ingepakte context uit voor een sub-thread.

20 Op dezelfde wijze als bij het enkel-threaded proces zendt de bron- gateway ook een "start proces" signaal 8 naar de doel-gateway 2. Dit "start proces" signaal 8 is een verzoek om een proces 4a te starten op het doelknooppunt. Het proces 4a heeft aanvankelijk slechts één thread, die de hoofd-thread zal worden wanneer de andere thread start. De thread 4a voert 25 een registratie 10 uit en voorbereiding 11, zoals hiervoor beschreven. De thread 4a zendt vervolgens een "hold" signaal 12 naar de doel-gateway. Wanneer de "hold" signalen van de bron-gateway 1 en de thread 4a zijn ontvangen, zendt de doel-gateway 2 een "luister" signaal naar de thread 4a (nieuwe incarnatie). De thread 4a is dan in een luistermodus. De doel-30 gateway 2 zendt tevens een "start uitzending" signaal 18 naar de bron-gateway, dat doorgegeven wordt aan de overgebleven (hoofd-) thread 3a van de oude incarnatie.

Verwezen wordt nu naar Afbeelding 2b, waarin de stappen worden 35 weergegeven die de voorbeeldimplementatie van de werkwijze verder 251 69 13 doorloopt. Het "start uitzending" signaal 18 wordt doorgegeven door de bron-gateway aan de overgebleven thread 3a door middel van een "zend" signaal 19. Een rechtstreekse communicatie 21 wordt vervolgens tot stand gebracht tussen de overgebleven thread 3a van de oude incarnatie en de eerste 5 thread 4a van de nieuwe incarnatie.

Telkens wanneer de eerste thread 4a de context van een sub-thread ontvangt, start de eerste thread 4a een sub-thread met de ontvangen context. De sub-threads 4b, 4c zijn in een hold-toestand. Wanneer de globale 10 context verzonden is, zendt de hoofd-thread 4a van de nieuwe incarnatie een "klaar" signaal 22 naar de the doel-gateway.

Na ontvangst van het "klaar” signaal 22, zendt de doel-gateway een "ga door” signaal 23 naar de hoofd-thread van de nieuwe incarnatie en 15 een "klaar” signaal 25 naar de overgebleven thread van de oude incarnatie. Het "ga door” signaal 23 maakt dat de threads 4a, 4b, 4c starten. De threads worden Immers ingedeeld door het OS. Dan heeft elke thread tijdens de uitvoeringsperiode zijn eigen synchronisatiepunt 28a, 28b, 28c.

20 Het "klaar” signaal 25 wordt door de bron-gateway doorgegeven aan de overgebleven thread 3a van de oude incarnatie door middel van een "breek af signaal 26. Dit "breek af signaal stopt de uitvoeringsactiviteiten van de overgebleven thread 3a, d.w.z., het stopt de uitvoering van de oude incarnatie.

25

Hoewel de beschreven speciale implementaties bijzonder gunstige eigenschappen bezitten, bestrijken zij niet alle mogelijkheden. Er is een verscheidenheid aan alternatieve implementaties mogelijk. Die alternatieven blijven binnen het door het octrooi bestreken kader van de uitvinding.

30

Het is bijvoorbeeld mogelijk om berichtenuitwisseling toe te passen in plaats van onderbrekingen om de betreffende signalen te verzenden. Het "verplaats" signaal 6 echter, moet wöl een onderbreking zijn, om te voorkomen dat de verplaatsactiviteiten worden gehinderd door 35 recursie.

1251 69

Claims (8)

1. Een werkwijze voor het verplaatsen van een proces van een bronknooppunt naar een doelknooppunt, waarbij: - een oude incarnatie van het proces (3), die in uitvoering is op het bronknooppunt, de eigen context in een frame (13) opslaat; 5. een nieuwe incarnatie van het proces (4) gestart wordt op het doelknooppunt, welke nieuwe incarnatie de status "gereed” heeft; - een rechtstreekse communicatie (21) tot stand wordt gebracht tussen de oude incarnatie (3) en de nieuwe incarnatie (4) van het proces, waarin de opgeslagen context verzonden wordt van de oude incarnatie naar de 10 nieuwe incarnatie; - de nieuwe incarnatie met verwerken begint (24), gebruikmakend van de ontvangen context.

2. Een procesverplaatswerkwijze volgens de vorige conclusie, waarin de 15 oude incarnatie (3) de eigen context regelmatig opslaat op vooraf bepaalde synchronisatiepunten (5), welke context na ontvangst van een signaal (6) van een bron-gateway (1) ingepakt wordt in een frame (13).

3. Een procesverplaatswerkwijze volgens een van de voorgaande 20 conclusies, waarbij de context de inhoud van het geheugen en de status van het proces bevat.

4. Een procesverplaatswerkwijze volgens een van de voorgaande conclusies, waarin de nieuwe incarnatie (4) gestart wordt na ontvangst van 25 een signaal (9) van een doel-gateway (2).

5. Een procesverplaatswerkwijze volgens de vorige .conclusie, waarin het signaal (9) voor het starten van de nieuwe incarnatie verzonden wordt na ontvangst van een signaal (8) van de bron-gateway (1). 30

6. Een procesverplaatswerkwijze volgens een van de voorgaande conclusies, waarin de rechtstreekse communicatie (21) tot stand wordt gebracht door middel van een Socket, het poortnummer waarvan: 251 69 - door de nieuwe incarnatie gezonden (12) wordt naar de doel-gateway, en vervolgens - door de doel-gateway gezonden (18) wordt naar de bron-gateway, en vervolgens 5. door de bron-gateway gezonden (19) wordt naar de oude incarnatie.

7. Een procesverplaatswerkwijze volgens een van de voorgaande conclusies, waarin de oude en nieuwe incarnaties multi-threaded processen zijn. 10

8. Een procesverplaatswerkwijze volgens de vorige conclusie, waarin elke thread (3a, 3b, 3c) van de oude incarnatie de eigen context opslaat, waarbij één (3a) van deze threads een hoofd-thread is en de opgeslagen contexten door de hoofd-thread (3a) ingepakt worden in één enkel frame. 251 69