DE19617976A1 - Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen - Google Patents
Kommunikationssystem mit Mitteln zum Austausch von SoftwareprozessenInfo
- Publication number
- DE19617976A1 DE19617976A1 DE19617976A DE19617976A DE19617976A1 DE 19617976 A1 DE19617976 A1 DE 19617976A1 DE 19617976 A DE19617976 A DE 19617976A DE 19617976 A DE19617976 A DE 19617976A DE 19617976 A1 DE19617976 A1 DE 19617976A1
- Authority
- DE
- Germany
- Prior art keywords
- exchange
- thread
- old
- application
- new
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
Description
Die Erfindung bezieht sich auf ein Kommunikationssystem mit einer Steuer
schaltung, welche
- - ein nachrichtenorientiertes Betriebssystem, Anwendungssoftware und Mittel zum Austausch von Anwendungssoftware enthält, und
- - im Austauschfall dazu vorgesehen ist, eine zu ersetzende, alte Softwarekomponente zu veranlassen einen Zustandstransfer durchzuführen und an einem bestimmten Punkt anzuhalten und einer neuen Software komponente die anliegenden Nachrichten zuzuleiten.
Kommunikationssysteme enthalten Computersysteme oder Steuerschaltungen, deren
Software langlebig und praktisch dauernd verfügbar sein soll. Bei Fehlern in der
Software oder auch aufgrund neuer Anforderungen müssen bestimmte Software
komponenten erneuert werden. Dabei sollte die Ausfallzeit des Kommunikations
systems minimiert werden.
Ein Kommunikationssystem, welches paktisch keine Ausfallzeit bei dem Austausch
einer Softwarekomponente eines Vermittlungssystems aufweist, ist aus der
US-A-5 155 837 bekannt. Vor dem Austausch werden zuerst die Inhalte und
Zustände aller Register, Prozesse und Speichereinheiten in einem speziellen Speicher
während des Betriebes der alten Software gesichert (Spalte 7, Zeilen 30 bis 36). Die
alte Version der Software ist dabei in einer ersten Partition geladen. Die neue
Software wird anschließend in eine zweite Partition geladen. Nachdem die neue
Software geladen und getestet worden ist, werden aus dem Speicher die Inhalte und
Zustande aller Register, Prozesse und Speichereinheiten auf die neue Software
übertragen. Diese wird dann in Betrieb genommen. Die neue Software beginnt dabei
jedoch nicht an dem Prozeßpunkt zu arbeiten, an dem die alte Software angehalten
worden ist, sondern an einem definierten Programmpunkt. Es werden auch nicht
einzelne Softwaremodule oder -komponenten, sondern eine in sich geschlossene
Software ausgetauscht.
Des weiteren ist aus dem Dokument "Elektrisches Nachrichtenwesen, Band 64,
Nummer 4, 1990, Seiten 327 bis 333" bekannt, Softwarekomponenten während des
Betriebes beispielsweise einer Vermittlungsanlage auszutauschen. Hierbei wird von
dem System bei einem Austausch ein alte Softwarekomponente zur Durchführung
eines erforderlichen Zustandstransfers veranlaßt. Beim Erreichen von vordefinierten
Synchronisationspunkten wird die alte Softwarekomponente angehalten und
Nachrichten von der alten zur neuen Softwarekomponente umgeleitet. Die neue
Softwarekomponente wird gestartet und die alte Softwarekomponente beendet und
entfernt. Einzelheiten über den Aufbau der zum Austausch vorgesehenen Programme
lassen sich dem Dokument nicht entnehmen.
Der Erfindung liegt daher die Aufgabe zugrunde, eine realisierbare Austausch
prozedur von Softwarekomponenten anzugeben, bei welcher außer einer kurzen
Verzögerung keine Einschränkung des Betriebes erfolgt.
Die Aufgabe wird durch ein Kommunikationssystem der eingangs genannten Art
dadurch gelöst,
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads und einem Austauschthread enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens zur Sammlung seiner Zustände vorgesehen ist, nachdem die Anwendungsthreads des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread des alten Prozesses wenigstens zur Übertragung der Zustände über Austausch-Ports an einen neuen Prozeß vorgesehen ist.
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads und einem Austauschthread enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens zur Sammlung seiner Zustände vorgesehen ist, nachdem die Anwendungsthreads des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread des alten Prozesses wenigstens zur Übertragung der Zustände über Austausch-Ports an einen neuen Prozeß vorgesehen ist.
Die erfindungsgemäße Austauschprozedur betrifft Prozesse mit beispielsweise
mehreren Threads (in sich selbst sequentiell ablaufende Programmstücke), die für
die Steuerung des Austausches einen Austauschthread enthalten. Durch die
Erfindung wird der Neustart wenigstens eines neuen Prozesses an dem
entsprechenden Programmpunkt (Austauschpunkt) durchgeführt, an dem der alte
Prozeß angehalten worden ist. Außerdem werden alle Zustände des alten Prozesses
mittels eines Austauschthreads des alten Prozesses zum neuen Prozeß übertragen.
Dies kann aber nur für solche Systeme gelten, die ein Betriebssystem aufweisen,
welches den Austausch von Nachrichten zwischen Softwarekomponenten ermöglicht
(z. B. CHORUS). Hierbei werden Nachrichten über Softwareschnittstellen, die im
folgenden als Ports bezeichnet werden, zwischen verschiedenen Prozessen
ausgetauscht. Der Austausch der Zustände erfolgt dabei über Austausch-Ports des
alten und neuen Prozesses.
Der Austausch eines Prozesses erfolgt dabei so, daß kein anderer Prozeß davon
berührt wird. Die von einem anderen Klienten (anderer Prozeß) eintreffenden
Nachrichten werden nämlich auf den neuen Prozeß übertragen und nach dem
Austausch weiterverarbeitet. Der Austausch erfolgt dabei so, daß nur eine kurze
Verzögerung bei der Bearbeitung entsteht. Praktische Untersuchungen haben
ergeben, daß die Verzögerungszeit im Bereich weniger Millisekunden liegt.
Ein Kommunikationssystem kann ein Computersystem sein, eine Vermittlungsstelle,
ein Computernetzwerk oder auch Serversysteme, wie z. B. ein Vide-On-Demand-Server.
Ein Computerssystem enthält wenigstens einen Computer, in dem eine
Softwarekomponente ausgetauscht werden soll.
Ein Anwendungsthread enthält einen ersten Teil zur Sammlung wenigstens der
Zustände des Anwendungsthreads eines alten, zum Austausch vorgesehenen
Prozesses und ist zur Lieferung der gesammelten Zustände zum Austauschthread des
alten Prozesses vorgesehen. Ein Anwendungsthread eines neuen Prozesses enthält
einen zweiten Teil zur Übernahme der Zustände von dem Austauschthread des alten
Prozesses und zur Rekonstruktion von auf die Zustände bezogenen Objekten.
Der Austausch eines Prozesses wird von einem Austauschmanager eingeleitet.
Dieser ist in der Steuerschaltung als weitere Softwarekomponente enthalten und ist
zum Laden und Starten eines Prozesses und zur Kennzeichnung vorgesehen, ob ein
neu gestarteter Prozeß einen alten Prozeß zu ersetzen hat. Eine Wartungsvorrichtung
liefert einen neuen Prozeß über ein Übertragungsmedium an den Austauschmanager.
Bei einem vorgesehenen Austausch von mehreren Prozessen sind diese jeweils
hintereinander zum Austausch vorgesehen. Es wird also zuerst ein erster Prozeß
ausgetauscht und dann hintereinander die folgenden Prozesse. Die Steuerung bei
diesem Austausch mit mehreren Prozessen kann der Austauschmanager übernehmen.
Nach dem Laden und Starten eines neuen Prozesses, der zum Austausch eines alten
Prozesses vorgesehen ist, ist zuerst ein Sprung zu einem dem Austauschpunkt des
alten Prozesses entsprechenden Austauschpunkt durch Überspringen normaler
Programmabläufe vorgesehen.
Die Erfindung bezieht sich auch auf ein Computersystem mit wenigstens einem
Computer und ein Verfahren zum Austausch von Softwarekomponenten.
Ausführungsbeispiele der Erfindung werden nachstehend anhand der Figuren näher
erläutert. Es zeigen:
Fig. 1 ein Computersystem mit einer Wartungsvorrichtung und einem
Computer, der austauschbare Prozesse enthält,
Fig. 2 ein Computersystem, das ein lokales Netzwerk enthält,
Fig. 3 eine symbolische Darstellung eines Prozesses,
Fig. 4 eine symbolische Darstellung eines neuen und alten Prozesses
während des Austausches,
Fig. 5 eine symbolische Darstellung eines neuen und alten Prozesses nach
dem Austausch,
Fig. 6 ein Vermittlungssystem mit einer Wartungsvorrichtung und einer
Steuerschaltung, die austauschbare Prozesse enthält und
Fig. 7 ein Nachrichtenflußdiagramm zwischen einem alten und neuen
Prozeß.
In Fig. 1 ist ein Computersystem mit einem Computer 1 und einer Wartungs
vorrichtung 2 dargestellt. Der Computer enthält Hardwarekomponenten 3, ein
Betriebssystem 4, Anwendungssoftware 5 und einen Austauschmanager 6. Das
Betriebssystem 4 muß eine Kommunikation zwischen Softwarekomponenten der
Anwendungssoftware 5 über Nachrichten ermöglichen (z. B. nachrichtenorientiertes
Betriebssystem (message based operating system)). Die Nachrichten oder Daten
werden dabei über Softwareschnittstellen ausgetauscht. Im folgenden wird eine
Softwareschnittstelle als Port bezeichnet.
Der Austauschmanager 6 ist eine Softwareprogramm, mit dessen Hilfe Komponenten
der Anwendungssoftware 5 ausgetauscht werden können. Eine auszutauschende
Softwarekomponente ist ein Prozeß (actor), der mehrere Threads enthält. Ein Thread
ist ein in sich selbst sequentiell ablaufendes Programmstück. In der Fig. 1 sind die
einzelnen Softwarekomponenten durch Kreise dargestellt. Die Verbindungen
zwischen den Kreisen sollen Nachrichtenflüsse zwischen den Softwarekomponenten
andeuten.
Die Wartungsvorrichtung 2 könnte ein entfernt liegender Computer sein,
von dem aus eine neue Softwarekomponente geliefert wird. Hierbei ist es denkbar,
daß die neue Softwarekomponente an diesem Computer entwickelt und getestet wird.
Zur Übertragung der neuen Softwarekomponente können bekannte Übertragungs
medien und Protokolle verwendet werden. Beispielsweise ist eine Übertragung über
ein Telefonnetz möglich. Die neue Softwarekomponente könnte aber auch direkt in
den Computer 1 geladen werden (z. B. mit Hilfe einer lokalen Wartungsvorrichtung
(Laptop)).
In Fig. 2 ist ein weiteres Beispiel für ein Computersystem dargestellt. Das
Computersystem ist als lokales Netzwerk (local area network) ausgebildet, welches
über verschiedene Knoten (z. B. Personal Computer, Workstations etc.) verfügt, die
über Hardwareschnittstellen (z. B. Ethernet-Schnittstelle) miteinander gekoppelt sind.
Fig. 2 zeigt exemplarisch zwei Knoten 7 und 8 des Netzwerkes, die jeweils
Anwendungssoftware mit mehreren Prozessen 9 enthalten. Ein solcher Prozeß
enthält einen geschützen Adreßraum, verwaltet eine Anzahl von Ports, über die der
Prozeß mit anderen Prozessen Nachrichten 11 austauscht und - wie oben schon
erwähnt - mehrere Threads, die in Fig. 2 als Schlangenlinien dargestellt sind. Ein
Prozeß 9 kann nur Nachrichten 11 über seine Ports 10 senden oder empfangen. Die
Knoten 7 und 8 sind mit weiteren nicht dargestellten Knoten des Netzwerks über
eine Netzwerkverbindung 12 gekoppelt.
Threads in einem Prozeß können auch über eigene Ports Nachrichten austauschen.
Weiter können Nachrichten z. B. auch über Mutexes und Semaphores ausgetauscht
werden. Ein Mutex (mutual exclusions) stellt eine Methode dar, die nur einem
Thread den Zugriff auf einem bestimmten Bereich ermöglicht. Beispielsweise sollen
Daten von einen Thread zu einem Drucker gesendet werden. In diesem Fall wird
von dem Thread ein Mutex gesetzt, so daß nur dieser Thread Daten an den Drucker
senden kann. Ein anderer Thread kann dann keine Daten zum Drucker geben. Ein
Semaphore stellt eine Methode dar, die nur einer bestimmten Anzahl von Thread
den Zugriff auf einen bestimmten Bereich ermöglicht. Nachrichten zwischen
Threads von verschiedenen Prozessen können nur über die Ports der jeweiligen
Prozesse ausgetauscht werden.
Als verteiltes Betriebssystem für das lokale Netzwerk, von dem Fig. 2 einen
Ausschnitt zeigt, kann CHORUS (vgl. Rozier, M.; Abrossimov, V.; Armand, F.;
Boule, I.; Gien, M.; Guillemont, M.; Herrmann; F.; Kaiser, C.; Langlois, S.;
Leonard, P.; Neuhauser, W.: Overview of the CHORUS distributed operating
systems; CHORUS systemes Technical Report CS-TR-90-25, 1990) verwendet
werden. Für die Anwendungssoftware kann beispielsweise die Programmiersprache
C oder C++ gewählt werden.
Zur Steuerung des Austausches von wenigstens einem Prozeß 9 des Netzwerkes in
Fig. 2 ist noch ein Austauschmanager 12 in dem Knoten 7 enthalten. Dieser
Austauschmanager 12 könnte auch Bestandteil eines anderen Knoten (z. B. Knoten 8)
anstatt des Knotens 7 sein.
Bei der Ersetzung oder Austausch wenigstens eines Prozesses, der von dem Aus
tauschmanager 6 (Fig. 1) bzw. 12 (Fig. 2) gesteuert wird, wird die neue
Softwarekomponente (neuer Prozeß) in den Computer 1 (Fig. 1) bzw. in einen
Knoten 7 oder 8 des Netzwerkes (Fig. 2) geladen und gestartet. Anschließend
werden alle Anwendungsthreads der alten Softwarekomponente (alter Prozeß)
angehalten und der alte Prozeß sammelt die Zustände aller Objekte. Der neue
Prozeß erhält die von dem alten Prozeß gesammelten Zustände, und die Ports des
alten Prozesses mit allen anhängigen Nachrichten wandern zu dem neuen Prozeß.
Nachdem die Objektstrukturen zwischen dem alten und neuen Prozeß angepaßt
worden sind, werden die Threads des neuen Prozesses dann an dem Punkt gestartet,
der dem Punkt des alten Prozesses entspricht. Zum Schluß wird der alte Prozeß
gelöscht.
Damit dieser Austausch während des Betriebes des Computer oder des lokalen
Netzwerkes, durchgeführt werden kann, sind in den Komponenten bzw. Prozessen
der Anwendungssoftware noch bestimmte Veränderungen gegenüber nicht
austauschbaren Komponenten vorgenommen worden. In jedem Prozeß, der
austauschbar sein soll, ist ein zusätzlicher Thread, der als Austauschthread
bezeichnet wird und die Austauschprozedur durchführt, und weiter ein zusätzliches
Austausch-Port, welcher zur Kommunikation beim Austausch dient, enthalten.
In Fig. 3 ist symbolisch gezeigt, was ein zum Austausch geeigneter Prozeß enthalten
muß. Der Prozeß 13 ist als Quadrat und dessen Anwendungsthreads 14 jeweils als
Schlangenlinien dargestellt. Der Prozeß 13 tauscht Daten mit einem Klienten über
Ports 15. Ein Klient ist eine andere Softwarekomponente. Wie oben erwähnt, besitzt
der austauschbare Prozeß zusätzlich einen Austauschthread 16 und einen zusätzlichen
Austausch-Port 17.
Aus Fig. 4 sind die Nachrichtenflüsse ersichtlich, die bei einem Austausch oder
Ersetzung eines Prozesses ablaufen. Ein Klient 18 sendet Nachrichten zu einem Port
19 (im folgenden als Dienst-Port bezeichnet) eines bisher installierten Prozesses 20.
Der Prozeß 20 (Vorgängerkomponente) soll durch einen neuen Prozeß 21
(Nachfolgerkomponente) ersetzt werden. Nachdem die Nachfolgerkomponente 21
geladen und gestartet worden ist, wird von einem Austausch-Port 22 der
Nachfolgerkomponente 21 ein Austauschbefehl zum Austausch-Port 23 der Vor
gängerkomponente 20 gesendet. Der Austauschbefehl ist in Fig. 4 durch einen Pfeil
mit der Bezeichnung (1) angegeben. Nachdem die Vorgängerkomponente 20
angehalten hat, sammelt sie ihre Zustände und liefert sie an den Austausch-Port 22
der Nachfolgerkomponente 21 (Pfeil (2)). Nachdem alles übertragen worden ist,
wird dies der Vorgängerkomponente 20 mitgeteilt (Pfeil (3)). Dann wird für den
Klienten 18 das Dienst-Port 19 des alten Prozesses als neues Dienst-Port 24 mit den
anhängigen Nachrichten zugänglich. Diese Port-Wanderung ist durch den
gestrichelten Pfeil mit der Bezeichnung (4) angedeutet.
Fig. 5 zeigt dann den Nachrichtenfluß nach dem Austausch. Der Klient 18 sendet
jetzt Nachrichten zum Dienst-Port 24 der Nachfolgerkomponente 21. Die
Vorgängerkomponente 20 ist gelöscht, was durch die zwei gekreuzten Striche über
dem die Vorgängerkomponente 20 repräsentierenden Quadrat angedeutet ist.
Bei der oben angegebenen Austauschprozedur ist von einem austauschbaren Prozeß
ausgegangen worden. Falls mehrere Prozesse ausgetauscht werden sollen, kann diese
Austauschprozedur in Teilschritte zerlegt werden. Ein Teilschritt ist dabei der
Austausch jeweils eines Prozesses. Hierdurch ist es einfacher die Austauschprozedur
zu kontrollieren und der erforderliche Speicherbedarf ist geringer als bei einem
gleichzeitigen Tausch mehrerer Prozesse.
Ferner können bestimmte neue Prozesse, die einen alten Prozeß ersetzen sollen,
beispielsweise auch neue Funktionen aufweisen. Um die Kompatibilität mit dem
alten Prozeß zu erhalten, ist es erforderlich die bisherigen Funktionen weiter im
neuen Prozeß bereitzustellen. Wenn alle Klienten, welche die alten Funktionen
benutzt haben, verschwunden sind, kann die alte Funktionalität für ungültig erklärt
werden und bei einem späteren Austausch ganz verschwinden.
In den Fig. 1 und 2 sind zwei Anwendungsmöglichkeiten für eine austauschbare
Software während des Betriebes dargestellt. Eine weitere Anwendungsmöglichkeit
besteht für Systeme, welche zur Übertragung von Nachrichten vorgesehen sind. Ein
Beispiel ist ein Vermittlungssystem, dessen wesentliche Blöcke in Fig. 6 gezeigt
sind. Das Vermittlungssystem enthält ein Koppelfeld 25 welches auf
Eingangsleitungen 26 empfangene Signale an eine oder mehrere Ausgangsleitungen
27 weitergibt. Zur Steuerung des Koppelfeldes dient eine Steuerschaltung 28, die
außer den notwendigen Hardwarebestandteilen ein Betriebssystem,
Anwendungssoftware und einen Austauschmanager enthält. Zum Austausch von
Komponenten der Anwendungssoftware ist eine Wartungsvorrichtung 29 vorgesehen,
die mit der Steuerschaltung 28 auf dieselbe Weise wie die Wartungsvorrichtung 2
mit dem Computer 1 zusammenarbeitet.
Wie oben ausgeführt, ist ein Austauschthread Teil eines Prozesses und notwendig
zum Austausch des Prozesses. Ein solcher Austauschthread versieht die
Anwendungsthreads in dem Prozeß mit einer Schnittstelle, welche einen Prozeß
austauschbar macht. Eine Implementierung der Schnittstelle in der
Programmiersprache C++ ist eine Klassendefinition, die z. B. mit "ExcThread"
bezeichnet werden kann. Ein Anwendungsthread hat exakt eine Instanz von dieser
Klasse "ExcThread". Die Klasse weist drei Methoden auf: "getExcInfo",
"setExcInfo" und "restartPointReached".
Die Methode "ExcThread::getExcInfo" ist einmal zu Beginn jedes Anwendungs
thread aufzurufen. Sie liefert die Information, ob eine Anwendungskomponente neu
gestartet oder eine ältere Version dieser Komponente ersetzt wird. Bei einem Aus
tausch liefert die Methode "ExcThread::getExcInfo" den Zustand des Anwendungs
threads der älteren Komponente und einen Parameter, welcher den Punkt beschreibt,
an welchem der Anwendungsthread des neuen Prozesses wieder zu starten ist.
Sobald der Anwendungsthread des neuen Prozesses alle Objekte wieder rekonstruiert
hat, hat es die Methode "ExcThread::restartPointReached" aufzurufen. Diese
Methode wird zur Synchronisierung des Starts aller Anwendungsthreads verwendet.
Es muß garantiert werden, daß kein Anwendungsthread diese Methode verläßt,
bevor alle Threads diese benutzen. Dadurch wird gesichert, daß alle Objekte
initialisiert werden, bevor diese von irgendeinem Anwendungsthread benutzt
werden. Das ist insbesondere für solche Objekte wichtig, die verschiedene
Anwendungsthreads teilen, z. B. Ports oder Semaphores.
Die Methode "ExcThread::setExcInfo" ist einmal von jedem Anwendungsthread
aufzurufen, nachdem der Anwendungsthread für den Austausch gestoppt worden ist.
Diese Methode wird benötigt, um den gegenwärtigen Zustand dieses Anwendungs
thread seiner entsprechenden neuen Komponente zu liefern.
Ein Zustandstransfer wird benötigt, damit der neue Prozeß z:b. Zustände von dem
alten Prozeß übernimmt. Der Zustandstransfer wird zwischen dem Anhalten des
alten Prozesses und dem Starten des neuen Prozesses durchgeführt. Beispielsweise
ist ein Zustandstransfer erforderlich, um den Zustand eines alten Telefonbuches in
den Zustand eines neuen Telefonbuches abzubilden. Ein solcher Transfer ist z. B.
dann erforderlich, wenn ein neues Feld "Postleitzahlen" hinzukommt oder dieses
Feld einen anderen Typ erhält (z. B. 5 anstatt 4 Zeichen).
Der Zustandtransfer eines Prozesses bedeutet, daß alle Zustände seiner Objekte
übertragen werden müssen. Hierbei wird jedes Objekt mit zwei Methoden versehen.
Eine Methode holt die Zustände und eine Methode legt die Zustände ab.
Der Austauschvorgang beginnt durch das Anhalten aller Anwendungsthreads eines
Prozesses an einem Punkt, an dem sie anhalten können. Diese Punkte werden als
Anhaltepunkte bezeichnet. Bei Erreichen eines Anhaltepunktes in einem Thread wird
seine normale Operation abgebrochen und Operationen durchgeführt, die sich auf
den Austausch beziehen. Als Anhaltepunkte werden solche Synchronisations- und
Kommunikationspunkte gewählt, an denen ein Thread anhalten kann.
Es müssen beim neuen Prozeß zu den Anhaltepunkten entsprechende Punkte
vorhanden sein, an denen der neue Prozeß gestartet werden kann. Diese Punkte
werden Restartpunkte genannt. Die Anhalte- und Restartpunkte werden als
Austauschpunkte bezeichnet. Der neue Prozeß kann sich gegenüber dem alten
Prozeß im Programmcode und bei den Objektstrukturen unterscheiden. Einige
Objekte können beim neuen Prozeß verschwunden, hinzugefügt oder verändert
worden sein.
Folgende Punkte sind Beispiele für Austauschpunkte:
Port::call
Port::receive
Semaphore::get
Mutex::get
Thread::delay.
Port::call
Port::receive
Semaphore::get
Mutex::get
Thread::delay.
Es ist hierbei die Schreibweise der Programmiersprache C++ gewählt worden.
Zuerst wird der Klassenname eingeführt und nach den beiden Doppelpunkten der
Methodenname (ClassName::MethodName). Beispielsweise bedeutet "Mutex::get"
eine Methode "get", die für alle Objekte vom Typ "Mutex" verfügbar ist.
Falls die Zeit für einen Austausch zu lang ist, könnte ein Problem bei bestimmten
Anwendungen auftreten (z. B. beim Austausch von Softwarekomponenten in einer
Vermittlungsanlage). Dies tritt auf jeden Fall dann nicht ein, wenn folgende fünf
Bedingungen erfüllt sind:
- R1) Eine Anwendung läuft auf einem System mit einem einzigen Prozessor.
- R2) Die Last des Prozessors ist unter 100%.
- R3) Es ist sichergestellt, daß innerhalb eines gegebenen Zeitintervalls ein Prozeß eine bestimmte Prozessorzeit garantiert bekommt.
- R4) Es ist nicht erlaubt, daß ein Thread asynchron gestoppt wird, d. h. nicht an einem Anhaltepunkt gestoppt wird.
- R5) Ein in einem Austauschpunkt befindlicher Thread kann in der Weise abgebrochen werden, daß er den Anhaltepunkt verläßt und daß er normal weiterläuft.
Wenn ein Prozessor vorhanden ist (R1) und dieser Prozessor hat eine Last von unter
100% (R2), dann existiert ein Zeitpunkt, zu dem alle Threads eines Prozesses
angehalten worden sind. Wenn ein Austauschthread mit einer Priorität kleiner als die
Prioritäten der anderen Anwendungsthreads des Prozesses vorhanden ist, dann wird
der Austauschthread zu diesem Zeitpunkt aktiv, weil der Prozeß immer einen Teil
der verfügbaren Prozessorzeit innerhalb eines gegebenen Zeitintervalls erhält (R3).
Es ist garantiert, daß alle Anwendungsthreads mit Ausnahme des Austauschthreads
selbst an einem Anhaltepunkt gestoppt haben (R4). Der Austauschthread benutzt
dann die zur Verfügung gestellte Prozessorzeit zur Ausführung des Austausch
vorgangs und bricht dazu alle im Anhaltepunkt befindlichen Anwendungsthreads ab
(R5).
Wenn jeder Anhaltepunkt ein Austauschpunkt ist, steht häufig eine große Anzahl
von Austauschpunkten zur Verfügung. Viele von den Austauschpunkten können
einfache Mutex-Operationen sein, die den parallelen Zugriff auf gemeinsame Daten
verhindern. Verschiedene Betriebssysteme erlauben nicht den einfachen Abbruch
von Threads, die in einem Mutex angehalten haben. Daher könnte ein Mutex, der
mit "Mutex::get" beginnt und mit "Mutex::rel" beendet wird, als potentieller
Austauschpunkt ausgeschlossen werden. Unter der Bedingung, daß zwischen
"Mutex::get" und "Mutex::rel" kein weiterer Anhaltepunkt liegt und daß der Mutex
nur von den Threads in demselben Prozeß benutzt wird, kann nachgewiesen werden,
daß kein Thread in diesem Mutex angehalten wird, wenn alle Threads angehalten
sind. Somit kann unter diesen Bedingungen ein Mutex als Austauschpunkt ausge
schlossen werden.
Bei der Realisierung eines Austauschpunktes wird eine Methode verwendet, bei der
sich der auszutauschende Thread selbst in einen Abbruchszustand versetzt. Das
Betriebssystem hebt in einem solchen Fall mit einem speziellen Rückkehrcode, der
außerdem einen Fehlercode "Abbruch" angibt, die Abbruchssituation auf. Dieser
Rückkehrcode bei einem Abbruch kann direkt als Signal für einen Austausch
interpretiert werden. Im folgenden ist ein in der Programmiersprache C++
geschriebenes Beispiel für "Port::receive" (Anhaltepunkt) aufgeführt, welches noch
zu einem nicht austauschbaren Thread gehört:
Die in Klammern angegebenen Nummern des Beispieles sind nicht Bestandteil des
Programmtextes und dienen nur zur Kennzeichnung der Zeilen. In Zeile (08) wird
der Puffer "buf" für die zu empfangenden Daten freigesetzt. Mit dem "receive"-Statement
in Zeile (09) wird der Puffer "buf" mit neuen Daten gefüllt. Der zweite
Parameter "TimeOutPeriod" des "receive"-Statements ist eine Zeitüberschreitungs
wert, der ein unendliche Wartezeit, z. B. bei einem durch einen Klienten verur
sachten Absturz, vermeiden soll. In Zeile (15) wird der Fehlercode für eine Zeit
überschreitung ("TimeOut") geprüft.
Um diesen Anhaltepunkt in einen Austauschpunkt umzuwandeln, ist das Beispiel für
"Port::receive" geändert worden, welches dann zu einem austauschbaren Thread
gehört:
Das obige Beispiel gibt die für den Austausch wesentlichen Programmteile eines
Austauschthread-Objektes an (Zeile (01)). Es werden nur die gegenüber dem
nichtaustauschbaren Beispiel "Port::receive" neu hinzugekommenden Zeilen
erläutert. In Zeile (10) wird der Fehlercode "Port::Aborted" geprüft, um
festzustellen, ob ein Austausch signalisiert worden ist. Wenn ein Austausch
durchgeführt werden soll, werden zuerst die Zustände der lokalen Objekte des
Threads gesammelt (Zeile (11)). Die Zustände werden in einem speziellen Objekt
vom Typ "Bin" gesammelt, welcher die Operatoren "" und "" definiert.
Der Operator "" sammelt die Zustände eines Objektes und der Operator ""
stellt sie wieder her. Dann kann der Thread Objekte löschen und andere Maßnahmen
vollziehen, um keine Resourcen zu verschwenden (Zeile (12)). Nach dem letzten
Aufruf von "excThread.setExchangeInfo" werden die gesammelten Zustände von
dem Austauschthread an den neuen Prozeß übertragen (Zeile (13)). Der erste
Parameter (ThreadName) gibt den aufgerufenen Thread an, der zweite Parameter
(ReceiveExcPointld) ist eine Integer-Variable, die den Austauschpunkt innerhalb des
aufgerufenen Threads angibt und der dritte Parameter (state) gibt die zu liefernden
Zustände an. Der Thread kehrt niemals von "setExchangeInfo" zurück.
Nachdem ein Austauschthread die Zustände eines alten Prozesses an einem Aus
tauschpunkt eingesammelt und den alten Prozeß gestoppt hat, ist es erforderlich, die
Threads von einem neuen Prozeß an einem entsprechenden Punkt (Restartpunkt) zu
starten. Hierbei kann das Problem auftauchen, daß der Restartpunkt in einer
Funktion liegt, die erst nach Aufruf verschiedener anderer Funktionen erreicht wird.
Daher sollte nach dem Aufruf des neuen Prozesses zuerst der Restartpunkt ohne
Ausführung anderer Statements erreicht werden. Dies kann beispielsweise in
Funktionen der Programmiersprache C++ mittels des "goto"-Befehls erreicht
werden. Hierbei wird am Beginn einer Funktion zuerst zu der Funktion gesprungen,
welche den Restartpunkt enthält. Dies kann auch über mehrere Funktionsebenen
erfolgen. Nach Erreichen des Restartpunktes werden die Zustandsvariablen neu
gesetzt und der neue Prozeß mit dem Statement weitergeführt, welches vor dem
Abbruch das nächste entsprechende Statement im alten Prozeß gewesen wäre.
Anhand des untenstehenden Beispiels kann gezeigt werden, wie dies praktisch
funktioniert:
Die Funktion "threadBody" (Zeile (15)) ruft die Funktion "fctA" und diese die
Funktion "fctB", welche den Restartpunkt enthält. Zuerst wird also in der Funktion
"threadBody" überprüft, ob "restart" wahr ist (Zeile (17)). Falls dies der Fall ist
wird der entsprechende Restartpunkt gewählt und zu dem entsprechenden Sprungziel
gesprungen (ExcPointX; Zeile (24)). Dort wird die Funktion "fctA" aufgerufen.
Innerhalb der Funktion "fctA" (Zeile (09) bis (14)) wird dieselbe Prozedur
wiederholt. Am Sprungziel "ExcPointX" (Zeile (12)) wird die Funktion "fctB" und
zum Sprungziel "ExcPointX" (Zeile (05)) innerhalb der Funktion "fctB" (Zeile (02)
bis (08)) gesprungen.
Nachdem der Restartpunkt erreicht worden ist, müssen die Objekte wieder
rekonstruiert werden. Zur Veranschaulichung soll das schon oben aufgeführte
Beispiel "Port::receive" dienen, welches zusätzlich eine Zustandstransformation
enthält. Diese Zustandstransformation ist bei dem unten aufgeführten Beispiel in den
Zeilen (01) bis (05) aufgeführt:
Die Rekonstruktion der Zustände nach dem Austausch (vgl. Zeile (05)) endet mit
einem Aufruf der Methode "excThread.restartPointReached" (Zeile (06)). Dadurch
wird der gleichzeitige Start aller Anwendungsthreads in dem neuen Prozeß gesichert.
Der Parameter "deliveredState" von "restartPointReached" wird benötigt, um zu
prüfen, ob der Zustand richtig gelesen worden ist.
Wie oben schon ausgeführt, kommunizieren Prozesse über Ports. Daher müssen die
Ports des alten Prozesses auch im neuen Prozeß vorhanden sein (Port-Wanderung).
Bei dem Betriebssystem CHORUS ist eine Port-Wanderung leicht zu
implementieren. Der Zustand eines Ports wird auf dieselbe Weise übertragen wie
der Zustand anderer Objekte. Der einzige Unterschied ist, daß der Zustand eines
Ports mit der speziellen Methode "Port::migrate" transferiert wird. Ein
Programmbeispiel, welches Bestandteil des alten Prozesses ist, ist nachstehend
aufgeführt:
Das gewanderte Port wird direkt aus dem gelieferten Zustand in dem neuen Prozeß
aufgebaut. Während der Zeit, welche für die Bearbeitung der Methode
"Port::migrate" verwendet wird, geht keine externe Nachricht verloren. Alle noch
ankommenden Nachrichten werden in eine Warteschlange des Ports eingereiht und
dem neuen Prozeß zusammen mit dem Port geliefert.
Fig. 7 zeigt zur weiteren Erläuterung des Austauschprozesses ein Nachrichten
flußdiagramm. Zuerst wird der Prozeß A1 gestartet. Der Prozeß A1 soll durch einen
Prozeß A2 ersetzt werden. Der Prozeß A1 stellt also eine Vorgängerkomponente
und der Prozeß A2 eine Nachfolgerkomponente dar. Gesteuert wird der Austausch
von einem Austauschmanager AM (Replacement Server), der als spezielle
Softwarekomponente in einem Knoten untergebracht ist. In der Fig. 7 ist der
Austauschmanagers AM jeweils als Rechteck mit der Bezeichnung AM dargestellt.
Das Nachrichtenflußdiagramm in Fig. 7 zeigt die Beziehungen der Anwendungs
threads der Prozesse AI und A2 und ihren jeweiligen Austauschthreads E(A1) und
E(A2). Zur Vereinfachung ist im Nachrichtenflußdiagramm der Fig. 7 nur ein
Anwendungsthread A(A1) und A(A2) für jeden Prozeß A1 und A2 aufgeführt. Der
Nachrichtenfluß, der durch verschiedene Mechanismen (z. B.: "Port::send/Port::receive";
"Semaphore::get/ Semaphore::rel") realisiert wird, wird jeweils
durch Pfeile gekennzeichnet.
Im Nachrichtenflußdiagramm von Fig. 7 wird zuerst der Prozeß A1 geladen und
gestartet (Punkt P1). Dieser erzeugt den Austauschthread E(A1) (Pfeil CET) und
gibt eine Nachricht (Pfeil NACH1) an den Austauschmanager AM. Der
Austauschmanager AM antwortet (Pfeil OKS) und gibt damit an, daß keine
Nachfolgerkomponente existiert. Anschließend synchronisiert ein Anwendungsthread
A(A1) des Prozesses A1 den Start des Austauschthreads E(A1) des Prozesses A1
(Pfeil SYNCS1). Danach gehen die Anwendungsthreads zu ihren eigentlichen
Aufgaben über (Punkt P2).
Nach der Synchronisierung des Starts des Austauschthreads E(A1) des Prozesses A1
durch einen Anwendungsthread A(A1) des Prozesses A1 setzt der Austauschthread
E(A1) seine Priorität kleiner als die Priorität der Anwendungsthreads A(A1) (Punkt
P3). Dies wird durchgeführt, um den Einfluß des Austauschthreads E(A1) auf die
Anwendungsthreads A(A1) so gering wie möglich zu halten. Weiter wird am Punkt
P3 von dem Austauschthread E(A1) ein Austausch-Port erzeugt damit dieser für die
Nachfolgerkomponente (Prozeß A2) erreichbar ist. Danach signalisiert der
Austauschthread E(A1) dem Austauschmanager AM, daß er für einen Austausch
bereit ist (Pfeil RFG1).
Wenn der Prozeß A2 als Nachfolgerkomponente des Prozesses A1 (Vorgänger
komponente) geladen und gestartet (Punkt P4) und ein Austauschthread E(A2) des
zweiten Prozesses A2 erzeugt worden ist (Pfeil CET2), wird zuerst eine Nachricht
(Pfeil NACH2) an den Austauschmanager AM gesendet. Der Austauschmanager AM
sendet eine Antwort (Pfeil OKR) an einen der Anwendungsthreads A(A2) des
Prozesses 2, die angibt, daß die Nachfolgerkomponente eine Vorgängerkomponente
(Prozeß A1) zu ersetzen hat. Daraufhin erzeugt dieser Anwendungsthreads des
Prozesses A2 eine entsprechende Referenz auf das Austausch-Port (Punkt PS) der
Vorgängerkomponente und meldet dem Austauschthread E(A1) des Prozesses A1,
daß die Austauschprozedur begonnen hat (Pfeil STARE).
Durch diese Nachricht des Prozesses A2 wird der Austauschthread E(A1) des ersten
Prozesses aktiviert. Als erstes macht dieser seinen Austausch-Port unzugänglich,
damit vermieden wird, daß eine andere Komponente (Prozeß) eine
Austauschnachricht sendet (Punkt P6). Wenn alle Anwendungsthreads A(A1) des
Prozesses A1 angehalten haben, empfängt der Austauschthread E(A1) die Nachricht,
daß alle Threads angehalten haben (Pfeil ALLBL), und gibt daraufhin einen
Abbruchbefehl (Pfeil ABTHR) an alle Anwendungsthreads A(A1) des ersten
Prozesses A1. Nach Empfang eines Befehls (Pfeil RETHR) zum Fortsetzen der
Austauschprozedur von dem Austauschthread E(A1) des ersten Prozesses A1,
sammelt jeder Anwendungsthread A(A1) des ersten Prozesses A1 seine Zustände
(Punkt P7), sendet ein Bestätigungssignal (Pfeil ABCOM) an den Austauschthread
E(A1) und löscht sich zum Schluß selbst (Punkt P8).
Der Austauschthread E(AI) des ersten Prozesses A1 sammelt die verschiedenen
Zustände der Anwendungsthreads A(A1) des ersten Prozesses A1 (Punkt P9) und
sendet diese zu dem Anwendungsthread A(A2) des zweiten Prozesses A2 (Pfeil
REPAS), der den Beginn der Austauschprozedur gemeldet hat (siehe Pfeil STARE).
Der empfangene Zustand wird an die Anwendungsthreads A(A2) weitergeleitet
(Punkt P10), die ihren Teil des Zustands übernehmen und ihre Objekte daraus
rekonstruieren (Punkt P11). Gleichzeitig wird der Austauschthread E(A2)
entsprechend informiert (Pfeil SYNCS2), der dann nach Erreichen aller Restart
punkte die Anwendungsthreads A(A2) zur Ausführung ihrer eigentlichen Aufgabe
freigibt (Pfeil STACO).
Zum Schluß signalisiert der Austauschthread E(A2) des zweiten Prozesses A2 dem
Austauschthread (E(A1) des ersten Prozesses A1, das die Austauschprozedur beendet
ist (Pfeil ALLAB). Der Austauschthread E(A1) des ersten Prozesses A1 sendet eine
Stopnachricht zum Austauschmanager (Pfeil STOP) und beendet sich selbst. Der
Austauschmanager E(A2) des zweiten Prozesses A2 bereitet sich dann darauf vor,
daß er später durch eine Nachfolgerkomponente abgelöst wird. Hierbei erzeugt er
einen Austausch-Port, setzt sich auf die geringste Priorität (Punkt P12) und
signalisiert dem Austauschmanager AM, daß er für einen Austausch bereit ist (Pfeil
RFG2).
Claims (10)
1. Kommunikationssystem mit einer Steuerschaltung (3; 7, 8; 28), welche
- - ein nachrichtenorientiertes Betriebssystem (4), Anwendungssoftware (5, 9) und Mittel zum Austausch von Anwendungssoftware (5, 9) enthält, und
- - im Austauschfall dazu vorgesehen ist, eine zu ersetzende, alte Softwarekomponente zu veranlassen einen Zustandstransfer durchzuführen und an einem bestimmten Punkt anzuhalten und einer neuen Software komponente die anliegenden Nachrichten zuzuleiten,
dadurch gekennzeichnet,
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads (14) und einem Austauschthread (16) enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens zur Sammlung seiner Zustände vorgesehen ist, nachdem die Anwendungsthreads (14) des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread (14) des alten Prozesses wenigstens zur Übertragung der Zustände über Austausch-Ports (17; 22, 23) an einen neuen Prozeß vorgesehen ist.
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads (14) und einem Austauschthread (16) enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens zur Sammlung seiner Zustände vorgesehen ist, nachdem die Anwendungsthreads (14) des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread (14) des alten Prozesses wenigstens zur Übertragung der Zustände über Austausch-Ports (17; 22, 23) an einen neuen Prozeß vorgesehen ist.
2. Kommunikationssystem nach Anspruch 1,
dadurch gekennzeichnet,
daß ein Anwendungsthread (14) einen ersten Teil zur Sammlung wenigstens der Zustände des Anwendungsthreads (14) eines alten, zum Austausch vorgesehenen Prozesses enthält und zur Lieferung der gesammelten Zustände zum Austauschthread (16) des alten Prozesses vorgesehen ist und
daß ein Anwendungsthread (14) eines neuen Prozesses einen zweiten Teil zur Übernahme der Zustände von dem Austauschthread (16) des alten Prozesses und zur Rekonstruktion von auf die Zustände bezogenen Objekten enthält.
daß ein Anwendungsthread (14) einen ersten Teil zur Sammlung wenigstens der Zustände des Anwendungsthreads (14) eines alten, zum Austausch vorgesehenen Prozesses enthält und zur Lieferung der gesammelten Zustände zum Austauschthread (16) des alten Prozesses vorgesehen ist und
daß ein Anwendungsthread (14) eines neuen Prozesses einen zweiten Teil zur Übernahme der Zustände von dem Austauschthread (16) des alten Prozesses und zur Rekonstruktion von auf die Zustände bezogenen Objekten enthält.
3. Kommunikationssystem nach Anspruch 1 oder 2,
dadurch gekennzeichnet,
daß die Steuerschaltung (3; 7, 8; 28) einen Austauschmanager (6, 12) als weitere
Softwarekomponente enthält, die zum Laden und Starten eines Prozesses und zur
Kennzeichnung vorgesehen ist, ob ein neu gestarteter Prozeß einen alten Prozeß zu
ersetzen hat.
4. Kommunikationssystem nach Anspruch 1, 2 oder 3,
dadurch gekennzeichnet,
daß nach dem Laden und Starten eines neuen Prozesses, der zum Austausch eines
alten Prozesses vorgesehen ist, zuerst ein Sprung zu einem dem Austauschpunkt des
alten Prozesses entsprechenden Austauschpunkt durch Überspringen normaler
Programmabläufe vorgesehen ist.
5. Kommunikationssystem nach einem der Ansprüche 1 bis 4,
dadurch gekennzeichnet,
daß bei einem vorgesehenen Austausch von mehreren Prozessen diese jeweils
hintereinander zum Austausch vorgesehen sind.
6. Kommunikationssystem nach einem der Ansprüche 1 bis 5,
dadurch gekennzeichnet,
daß eine Wartungsvorrichtung (2, 29) zur Lieferung einer neuen Software
komponente über ein Übertragungsmedium an den Austauschmanager (6, 12)
vorgesehen ist.
7. Computersystem mit wenigstens einem Computer (1; 7, 8), welche
- - ein nachrichtenorientiertes Betriebssystem (4), Anwendungssoftware (5, 9) und Mittel zum Austausch von Anwendungssoftware (5, 9) enthält, und
- - im Austauschfall dazu vorgesehen ist, eine zu ersetzende, alte Softwarekomponente zu veranlassen einen Zustandstransfer durchzuführen und an einem bestimmten Punkt anzuhalten und einer neuen Software komponente die anliegenden Nachrichten zuzuleiten,
dadurch gekennzeichnet,
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads (14) und einem Austauschthread (16) enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens zur Sammlung seiner Zustände vorgesehen ist, nachdem die Anwendungsthreads (14) des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread (14) des alten Prozesses wenigstens zur Übertragung der Zustände über Austausch-Ports (17; 22, 23) an einen neuen Prozeß vorgesehen ist.
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads (14) und einem Austauschthread (16) enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens zur Sammlung seiner Zustände vorgesehen ist, nachdem die Anwendungsthreads (14) des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread (14) des alten Prozesses wenigstens zur Übertragung der Zustände über Austausch-Ports (17; 22, 23) an einen neuen Prozeß vorgesehen ist.
8. Verfahren zum Austausch von Softwarekomponenten für ein System mit einem
nachrichtenorientierten Betriebssystem (4), Anwendungssoftware (5, 9) und Mittel
zum Austausch von Anwendungssoftware (5, 9),
bei dem im Austauschfall eine zu ersetzende, alte Softwarekomponente veranlaßt
wird, einen Zustandstransfer durchzuführen und an einem bestimmten Punkt
anzuhalten und einer neuen Softwarekomponente die anliegenden Nachrichten
zuzuleiten,
dadurch gekennzeichnet,
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads (14) und einem Austauschthread (16) enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens seine Zustände sammelt, nachdem die Anwendungsthreads (14) des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread (14) des alten Prozesses wenigstens die Zustände über Austausch-Ports (17; 22, 23) an einen neuen Prozeß überträgt.
daß die Anwendungssoftware wenigstens einen Prozeß mit wenigstens einem Anwendungsthreads (14) und einem Austauschthread (16) enthält,
daß ein alter, zum Austausch vorgesehener Prozeß wenigstens seine Zustände sammelt, nachdem die Anwendungsthreads (14) des alten Prozesses an einem Austauschpunkt angehalten haben, und
daß der Austauschthread (14) des alten Prozesses wenigstens die Zustände über Austausch-Ports (17; 22, 23) an einen neuen Prozeß überträgt.
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19617976A DE19617976A1 (de) | 1996-05-06 | 1996-05-06 | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen |
DE59710399T DE59710399D1 (de) | 1996-05-06 | 1997-04-25 | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen |
EP97201240A EP0807883B1 (de) | 1996-05-06 | 1997-04-25 | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen |
US08/851,305 US6634025B1 (en) | 1996-05-06 | 1997-05-05 | System for exchanging software processes during execution using threads |
JP11560697A JP3912441B2 (ja) | 1996-05-06 | 1997-05-06 | 通信システム、コンピュータシステム及びソフトウェアコンポーネント交換方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19617976A DE19617976A1 (de) | 1996-05-06 | 1996-05-06 | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen |
Publications (1)
Publication Number | Publication Date |
---|---|
DE19617976A1 true DE19617976A1 (de) | 1997-11-13 |
Family
ID=7793362
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19617976A Withdrawn DE19617976A1 (de) | 1996-05-06 | 1996-05-06 | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen |
DE59710399T Expired - Fee Related DE59710399D1 (de) | 1996-05-06 | 1997-04-25 | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE59710399T Expired - Fee Related DE59710399D1 (de) | 1996-05-06 | 1997-04-25 | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen |
Country Status (4)
Country | Link |
---|---|
US (1) | US6634025B1 (de) |
EP (1) | EP0807883B1 (de) |
JP (1) | JP3912441B2 (de) |
DE (2) | DE19617976A1 (de) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999039266A1 (en) * | 1998-01-30 | 1999-08-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Software upgrade |
US6385770B1 (en) | 1999-01-29 | 2002-05-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Software upgrade |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001043070A (ja) * | 1999-07-29 | 2001-02-16 | Nec Corp | 設定情報自動復帰方法及び装置並びに設定情報自動復帰プログラムを記録した記録媒体 |
FR2810423A1 (fr) * | 2000-06-16 | 2001-12-21 | Suntech | Systeme informatique modulaire et procede associe |
GB2411995B (en) * | 2001-04-11 | 2005-10-26 | Sun Microsystems Inc | Performing upgrades of a Java platform |
US7370322B1 (en) * | 2001-04-11 | 2008-05-06 | Sun Microsystems, Inc. | Method and apparatus for performing online application upgrades in a java platform |
US20030005408A1 (en) * | 2001-07-02 | 2003-01-02 | Pradeep Tumati | System and method for creating software modifiable without halting its execution |
US20030092438A1 (en) * | 2001-11-14 | 2003-05-15 | Moore Brian J. | Method and apparatus for stabilizing calls during a system upgrade or downgrade |
US7117506B2 (en) | 2002-02-07 | 2006-10-03 | Mobitv, Inc. | Plug-in API for modular network transaction processing |
WO2003069475A2 (en) * | 2002-02-07 | 2003-08-21 | Idetic, Inc. | A plug-in api for modular network transaction processing |
US7234056B2 (en) * | 2002-09-24 | 2007-06-19 | Inrange Technologies Corp. | Method and apparatus for downloading executable code in a non-disruptive manner |
US7698700B2 (en) * | 2003-04-17 | 2010-04-13 | International Business Machines Corporation | System quiesce for concurrent code updates |
US8276136B2 (en) * | 2007-12-11 | 2012-09-25 | Red Hat, Inc. | Transparent configuration of a network appliance |
US8418164B2 (en) | 2008-05-29 | 2013-04-09 | Red Hat, Inc. | Image install of a network appliance |
CN101616028B (zh) * | 2009-06-25 | 2012-02-29 | 中兴通讯股份有限公司 | 一种通信程序业务不中断升级方法及系统 |
US8171137B1 (en) | 2011-05-09 | 2012-05-01 | Google Inc. | Transferring application state across devices |
US8224894B1 (en) | 2011-05-09 | 2012-07-17 | Google Inc. | Zero-click sharing of application context across devices |
US8812601B2 (en) * | 2011-05-09 | 2014-08-19 | Google Inc. | Transferring application state across devices with checkpoints |
US8819660B2 (en) * | 2011-06-29 | 2014-08-26 | Microsoft Corporation | Virtual machine block substitution |
US9184800B2 (en) | 2012-07-16 | 2015-11-10 | Google Inc. | Automated sharing of application data over a near field communication link |
US9125180B1 (en) | 2013-03-15 | 2015-09-01 | Google Inc. | Techniques for automatically establishing a long-lasting connection across computing devices configured for short-range wireless communication |
US20150143354A1 (en) * | 2013-11-19 | 2015-05-21 | Suresh Mathew | Zero downtime deployment and rollback |
CN105450782B (zh) | 2016-01-15 | 2018-11-06 | 网宿科技股份有限公司 | 一种无丢包零停机重启网络服务的方法和系统 |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5155847A (en) * | 1988-08-03 | 1992-10-13 | Minicom Data Corporation | Method and apparatus for updating software at remote locations |
US4954941A (en) * | 1988-08-31 | 1990-09-04 | Bell Communications Research, Inc. | Method and apparatus for program updating |
US5155837A (en) | 1989-03-02 | 1992-10-13 | Bell Communications Research, Inc. | Methods and apparatus for software retrofitting |
US5210854A (en) * | 1989-06-14 | 1993-05-11 | Digital Equipment Corporation | System for updating program stored in eeprom by storing new version into new location and updating second transfer vector to contain starting address of new version |
JP2886961B2 (ja) * | 1990-09-19 | 1999-04-26 | 株式会社日立製作所 | プログラム入替方法 |
JP2582956B2 (ja) * | 1991-05-07 | 1997-02-19 | 三菱電機株式会社 | プログラマブル制御装置 |
US5410703A (en) * | 1992-07-01 | 1995-04-25 | Telefonaktiebolaget L M Ericsson | System for changing software during computer operation |
JP2741994B2 (ja) * | 1992-08-28 | 1998-04-22 | 富士通株式会社 | ジョブ環境動的変更機能を持つ処理装置および処理方法 |
JPH0683605A (ja) * | 1992-09-07 | 1994-03-25 | Fujitsu Ltd | 改変したプログラムを実行するデータ処理方式 |
US5359730A (en) * | 1992-12-04 | 1994-10-25 | International Business Machines Corporation | Method of operating a data processing system having a dynamic software update facility |
US5613133A (en) * | 1994-09-09 | 1997-03-18 | Unisys Corporation | Microcode loading with continued program execution |
US5682533A (en) * | 1994-09-27 | 1997-10-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Updating software within a telecommunications switch without interrupting existing communication and neither moving nor converting data |
SE504943C2 (sv) * | 1994-12-09 | 1997-06-02 | Ericsson Telefon Ab L M | Synkroniseringsförfarande som tillåter tillståndsöverföring |
US5619698A (en) * | 1995-05-05 | 1997-04-08 | Apple Computer, Inc. | Method and apparatus for patching operating systems |
US5764992A (en) * | 1995-06-06 | 1998-06-09 | Apple Computer, Inc. | Method and apparatus for automatic software replacement |
US5845077A (en) * | 1995-11-27 | 1998-12-01 | Microsoft Corporation | Method and system for identifying and obtaining computer software from a remote computer |
US6161218A (en) * | 1996-01-16 | 2000-12-12 | Sun Microsystems Inc. | Software patch architecture |
US5761504A (en) * | 1996-02-16 | 1998-06-02 | Motorola, Inc. | Method for updating a software code in a communication system |
US6049671A (en) * | 1996-04-18 | 2000-04-11 | Microsoft Corporation | Method for identifying and obtaining computer software from a network computer |
US5797016A (en) * | 1996-10-29 | 1998-08-18 | Cheyenne Software Inc. | Regeneration agent for back-up software |
US6202205B1 (en) * | 1998-07-21 | 2001-03-13 | Hewlett-Packard Company | System and method for profile-based, on-the-fly optimization of library code |
-
1996
- 1996-05-06 DE DE19617976A patent/DE19617976A1/de not_active Withdrawn
-
1997
- 1997-04-25 EP EP97201240A patent/EP0807883B1/de not_active Expired - Lifetime
- 1997-04-25 DE DE59710399T patent/DE59710399D1/de not_active Expired - Fee Related
- 1997-05-05 US US08/851,305 patent/US6634025B1/en not_active Expired - Fee Related
- 1997-05-06 JP JP11560697A patent/JP3912441B2/ja not_active Expired - Fee Related
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1999039266A1 (en) * | 1998-01-30 | 1999-08-05 | Telefonaktiebolaget Lm Ericsson (Publ) | Software upgrade |
AU753343B2 (en) * | 1998-01-30 | 2002-10-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Software upgrade |
US6385770B1 (en) | 1999-01-29 | 2002-05-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Software upgrade |
Also Published As
Publication number | Publication date |
---|---|
EP0807883A3 (de) | 2000-05-31 |
EP0807883A2 (de) | 1997-11-19 |
EP0807883B1 (de) | 2003-07-09 |
JPH10143377A (ja) | 1998-05-29 |
DE59710399D1 (de) | 2003-08-14 |
US6634025B1 (en) | 2003-10-14 |
JP3912441B2 (ja) | 2007-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP0807883B1 (de) | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen | |
EP0743595B1 (de) | Kommunikationssystem mit Mitteln zum Austausch von Software | |
DE60220287T2 (de) | System und verfahren zur überwachung von software-warteschlangenanwendungen | |
DE3908459C2 (de) | Netzwerkserver | |
DE4497149B4 (de) | Computerbezogenes Verfahren zur Datenreplikation in Peer-to-Peer-Umgebung | |
DE69937715T2 (de) | Verbessertes Zwei-Phasen-Bindungsprotokoll | |
DE60306932T2 (de) | Schnelle Datenbankreplikation | |
DE4303062C2 (de) | Verfahren zur Behebung von Systemausfällen in einem verteilten Computersystem und Vorrichtung zur Durchführung des Verfahrens | |
EP0635792B1 (de) | Verfahren zur Koordination von parallelen Zugriffen mehrerer Prozessoren auf Resourcenkonfigurationen | |
DE4033336A1 (de) | Verfahren zum erzeugen einer ausfallmeldung und mechanismus fuer ausfallmeldung | |
EP0525432A2 (de) | Verfahren zur Änderung von Systemkonfigurationsdatensätzen in einem Fernmeldevermittlungssystem | |
DE2243956A1 (de) | Speicherprogrammierte datenverarbeitungsanlage | |
DE4011745A1 (de) | Taskverfolgungseinrichtung | |
EP2648094B1 (de) | Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses | |
WO2001037058A1 (de) | Automatisierungsgerät und aufdat-verfahren | |
EP0632668A2 (de) | Verfahren zum Aktualisieren eines Systemprogramms in einer Vermittlungseinrichtung | |
WO2005018193A1 (de) | Verfahren und system zur ereignisübertragung | |
DE19640346C2 (de) | Verfahren zum Überprüfen eines gemäß einem Kommunikationsprotokoll durchgeführten Datenaustausches | |
EP1119801A1 (de) | Verfahren zum betrieb eines automatisierungssystems | |
WO1997004385A1 (de) | Rechnersystem | |
EP1536328B1 (de) | Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems | |
EP1437655A2 (de) | Rechner- und/oder Software-Architektur unter Verwendung von Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik | |
DE19520745C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
DE19520744C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
DE10360535B4 (de) | Einrichtung und Verfahren zur Steuerung und Kontrolle von Überwachungsdetektoren in einem Knoten eines Clustersystems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8139 | Disposal/non-payment of the annual fee |