DE3686018T2

DE3686018T2 - Betriebsfuehrung von hardwaremitteln.

Info

Publication number: DE3686018T2
Application number: DE8686111958T
Authority: DE
Inventors: Xuan Nghi Pham; John Hayden Wilson
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1985-10-11
Filing date: 1986-08-29
Publication date: 1993-03-04
Anticipated expiration: 2006-08-30
Also published as: CA1266529A; EP0218871B1; EP0218871A2; DE3686018D1; JPS6288037A; EP0218871A3; US4750116A; BR8604620A

Description

Anwendungsbereich

Diese Erfindung bezieht sich auf die Verwaltung von Hardware- Betriebsmitteln in einem Informationsverarbeitungssystem und genauer auf die Zuweisung von Hardware-Betriebsmitteln bei mehreren konkurrierenden Anwendungsprogrammen.

Stand der Technik

In einer Datenverarbeitungsumgebung werden Hardware-Betriebsmittel von mehreren im System ausgeführten Software-Anwendungen geteilt. Es ist nicht ungewöhnlich, daß mehr als eine Anwendung gleichzeitig dasselbe Hardware-Betriebsmittel anfordert. Da nicht mehrere Anwendungen dasselbe Hardware-Betriebsmittel gleichzeitig benutzen können, müssen Mittel bereitgestellt werden, um dieses Problem der Konkurrenz zu lösen. Es wurden verschiedene Verfahren vorgeschlagen, um dieses Hardware-Zugriffsproblem zu überwinden.
Bei einer Methode wird jeder konkurrierenden Anwendung, die die Hardware-Betriebsmittel des Systems benutzen möchte, ein Prioritätsniveau zugeordnet. Wenn zwei oder mehr Anwendungen eine gleichzeitige Ausführung erfordern, dann wird festgestellt, welche Anwendung die höchste Priorität besitzt. Der Anwendung mit der höchsten Priorität wird dann die Ausführung unter Benutzung der geforderten gestattet. Die Anwendung mit der niedrigeren Priorität wartet dann mit der Ausführung, bis die Hardware-Betriebsmittel von der Anwendung mit der höchsten Priorität nicht länger benötigt werden. Ein Problem dieser Methode besteht darin, daß sie dazu neigt, Anwendungen mit höherer Priorität gegenüber Anwendungen mit niedrigerer Priorität zu begünstigen, wodurch die Ausführung von Anwendungen mit niedriger Priorität wesentlich verzögert wird.
Eine Methode zur Überwindung dieses Problems besteht darin, einer Anwendung eine Priorität entsprechend dem Zeitraum zuzuweisen, den sie im Vergleich mit anderen wartenden Anwendungen auf die Ausführung gewartet hat. Bei einem anderen bekannten Verfahren wird derjenigen Anwendung die Priorität eingeräumt, die die kürzeste erwartete Ausführungszeit besitzt. Beispielsweise wird in der US-Patentschrift 4,096,571 die Wartezeit eines Prozessors minimiert, indem irgendein Prozessor daran gehindert wird, zweimal zum Speicher zuzugreifen, bevor ein anderer Prozessor, der in der Zwischenzeit den Speicher angefordert hat, einmal zugreift. Bei einer weiteren in der US-Patentschrift 4,481,583 dargestellten Methode werden die Programme in einer Folge von Verarbeitungsintervallen abgearbeitet. Nach jedem Intervall wird die Priorität des ausgeführten Programmes verringert, im Verhältnis zur Menge der verwendeten Betriebsmitteln. Nach jedem Verarbeitungsintervall werden die Prioritäten für alle Programme, die um den Zugriff zu den gleichen Betriebsmitteln konkurrieren, neu berechnet.
In der US-Patentschrift 4,514,728 wird das Problem der Blockieruniner niedrigen Priorität behandelt. Eine Blockierung einer niedrigen Priorität kann beispielsweise auftreten, wenn sich zwei Anwendungen hoher Priorität zufällig am gleichen System- Betriebsmittel abwechseln, gemeinsam mit einer Anwendung niedriger Priorität. Diese Konkurrenz wird niemals zugunsten der Anwendung mit niedrigerer Priorität aufgelöst; damit wird sie vom Zugriff zum gewünschten Systemelement ausgesperrt. Entsprechend diesem Patent werden alle Anforderungen nach einem Systeme-Betriebsmittel zu einer bestimmten Zeit gespeichert. Weitere Forderungen werden nicht entgegengenommen, bis jeder Anwendung, die mit einer gespeicherten Anforderung verbunden ist, Zugang zu dem Systemelement gewährt wurde. Auf diese Weise wird eine Anwendung mit niedrigerer Priorität nicht blockiert.
EP-A-0 093 835 mit dem Titel "Resource switching in a multitasking environment" zeigt ein Signalverarbeitungssystem, das Mittel enthält, einem ersten Anwendungsprogramm einige Betriebsmittel zu entziehen, um einem zweiten Anwendungsprogramm unter Benutzung der genannten Betriebsmittel die Ausführung zu ermöglichen.
Ein bisher nicht behandeltes Problem zeigt sich, wenn ein Anwender eine Anwendung starten möchte, die die gegenwärtig von einer anderen Anwendung benutzten Betriebsmittel beansprucht. Es müssen Mittel bereitgestellt werden, um festzustellen, welche Betriebsmittel jede Anwendung anfordert und welche Betriebsmittel aktuell verfügbar sind. Zusätzlich muß der Anwender gewarnt werden, wenn eine Anwendung eventuell unterbrochen wird, weil ihre Betriebsmittel angefordert werden, um eine andere Anwendung laufen zu lassen. Zusätzlich müssen Vorkehrungen getroffen werden, damit die Fortsetzung der Ausführung der unterbrochenen Anwendung nach dem Abschluß der unterbrechenden Anwendung möglich wird. Wenn in einer Umgebung mehr als eine Anwendung gleichzeitig laufen kann, dann müssen noch Mittel vorgesehen werden, um die angeforderten Betriebsmittel zu überwachen und sie auf die laufenden Anwendungen zu verteilen. Schließlich wäre es höchst wünschenswert, ein System in die Lage zu versetzen, einander widersprechende Verwendungen der gleichen Hardware-Betriebsmittel durch konkurrierende Anwendungen so zu erkennen, daß das System dem Anwender helfen kann, eine richtige Entscheidung zu treffen, welche Anwendung zuerst auszuführen ist.

Darstellung der Erfindung

Das durch den Gegenstand der vorliegenden Erfindung zu lösende technische Problem besteht darin, ein Mittel zur Verwaltung von Hardware-Betriebsmittel in einem Informationsverarbeitungssystem bereitzustellen, durch die es möglich ist, sich widersprechende Verwendungen von Hardware-Betriebsmittel durch konkurrierende Anwendungen so festzustellen, daß der Anwender bestimmen kann, welche Anwendung mit Priorität auszuführen ist.
Das Problem wird durch die Erfindung gemäß Anspruch 1 gelöst. Entsprechend der vorliegenden Erfindung wird ein Mittel bereitgestellt, damit unabhängige Anwendungsprogramme, die die gleichzeitige Verwendung derselben Hardware-Betriebsmittel eines Mehrfunktions-Signalverarbeitungssystems fordern, erkennen können, wenn sie sich widersprechende Betriebsmittel verwenden oder verwenden wollen. Ein Anwender darf eine Anwendung starten, die die Betriebsmittel beansprucht, die gegenwärtig von einer anderen Anwendung benutzt wird. Die Anwendung, der die Betriebsmittel entzogen wurden, wird identifiziert, so daß sie wieder aufgenommen werden kann, wenn die gewünschten Betriebsmittel erneut verfügbar werden.
Bevor die Betriebsmittel einer gegebenen Anwendung durch eine andere Anwendung entzogen werden, erhält der Nutzer eine Warnung, so daß er die Reihenfolge, in der die Anwendungen laufen, ändern kann.
Das Signalverarbeitungssystem der vorliegenden Erfindung enthält Funktionsgruppen zur Spracherkennung, zur Umwandlung von Text in Sprache, zur Sprachspeicherung und Sprachwiedergabe, für die Telefonund die asynchrone Kommunikation mit Modemkommunikation. Die Hardware-Betriebsmittel umfassen zwei Anschlüsse oder Kanäle, zwei Telefonleitungen, ein Telefon, einen Lautsprecher, ein Mikrofon und zwei Partitionen in einem Befehlsspeicher, um die oben genannten Funktionen bereitzustellen. Zusätzlich zu den Hardware-Betriebsmitteln gibt es auch Interrupt-Betriebsmittel. Diese Interrupt-Betriebsmittel umfassen das Einwählen auf beiden Telefonleitungen und einen Handapparat-Ein-Aus-Gabel für das Telefon-Betriebsmittel.
Eine Anwendung verkehrt mit dem Signalverarbeitungssystem durch einen Hauptrechner über eine Anwendungsprogrammschnittstelle. Der Signalverarbeitungscode wird auf einem Signalprozessor unter der Steuerung eines interruptgesteuerten Multitasking-Steuerprogramms ausgeführt, das sich in einer dritten Partition des Befehlsspeichers befindet. Dieses Signalprozessor-Steuerprogramm verwaltet die Partitionen im Befehlsspeicher und erlaubt, daß der Signalprozessorcode in den Partitionen parallel läuft. Der Signalverarbeitungscode in einer Partition entspricht einer Funktion in der Anwendungsprogrammschnittstelle. Das Subsystem der Anwendungsprogrammschnittstelle lädt den Signalprozessorcode in Antwort auf Schnittstellenbefehle des Anwendungsprogramms in die geeignete Partition. Die Funktionsgruppen in der Schnittstelle umfassen Telefon, Leitungsüberwachung, asynchrone Kommunikation, akustische Ein- und Ausgabe, Sprachsynthese (Text- Sprache) und Spracherkennung.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein vereinfachtes Funktions-Blockdiagramm des Signalverarbeitungssystems gemäß vorliegender Erfindung.
Fig. 2 ist ein Blockdiagramm der Hardware-Betriebsmittel des Signalverarbeitungssystems gemäß vorliegender Erfindung.
Fig. 3 ist ein funktionelles Blockdiagramm des Gesamtsystems der vorliegenden Erfindung.
Fig. 4 ist ein vereinfachtes Blockdiagramm, das den Befehlsfluß von einem Anwendungsprogramm über die Programmschnittstelle durch den Hauptrechner zum Signalverarbeitungssystem zeigt.
Fig. 5 ist ein vereinfachtes Blockdiagramm, das den Interrupt- Fluß vom Signalverarbeitungssystem und durch den Hauptrechner zurück zum Anwendungsprogramm zeigt.
Fig. 6 ist ein Flußdiagramm, das die Zuweisung der Betriebsmittel einer anfordernden Anwendung zeigt.

Die beste Ausführung der Erfindung

Ein vereinfachtes Funktions-Blockdiagramm des Signalverarbeitungssystems 50 ist in Fig. 1 dargestellt. Der Signalprozessor 88 kann irgendein kommerziell verfügbarer Signalprozessor wie etwa der Texas Instruments TMS32010 sein. Der Signalprozessor 88 wird vollständig von dem Hauptrechner 89 gesteuert und muß zu Beginn seine Zentraleinheits-(CPU)-Befehle geladen haben. Der Signalprozessor 88 benutzt den Befehlsspeicher 21 sowie den Datenspeicher 87. Auf diese beiden Speicher kann vom Hauptrechner 89 aus zugegriffen werden, aber nicht gleichzeitig mit dem Signalprozessor 88. Der Befehlsspeicher 21 ist vom Hauptrechner 89 nur zugänglich, wenn der Signalprozessor 88 ausgeschaltet, d. h. zurückgesetzt ist. Zu dieser Zeit kann der Hauptrechner 89 aus dem Befehlsspeicher 21 laden und dann zum Datenspeicher 87 umschalten, der immer gemeinsam mit dem Signalprozessor 88 dynamisch genutzt wird. Sowohl der Signalprozessor 88 als auch der Hauptrechner 89 besitzen die Fähigkeit, einander zu unterbrechen, mit Interruptmaskierung unter Steuerung des Hauptrechners 89.
Die für das Signalverarbeitungssystem verfügbaren Betriebsmittel sind in Fig. 2 dargestellt. Die Partitionen 12, 13 und 14 sind im Befehlsspeicher 21 enthalten (siehe Fig. 3). Die Partition 14 wird geladen, wenn das Verarbeitungssystem initialisiert wird und Funktionen bereitstellt, um die Betriebsmittel des Signalverarbeitungssystems zu verwalten. Partition 12 kann entweder die Telefon- oder die Leitungsüberwachungs-Funktionsgruppe enthalten. Die Telefonfunktionsgruppe liefert die Möglichkeit, Telefonnummern auf den Leitungen 34 und 35 zu wählen und den Fortschritt eines abgehenden Telefonrufs zu überwachen, während dieser bearbeitet wird. Die Leitungsüberwachungsfunktion ermöglicht, daß ein Anwendungsprogramm über ankommende Signale informiert wird, die von einem Telefonsystem erzeugt werden, nachdem eine Verbindung aufgebaut wurde.
Partition 13 kann beliebige Funktionsgruppen enthalten, die akustische Ein- und Ausgabe, Sprachsynthese (Text-in-Sprache), Spracherkennung und asynchrone Kommunikation über Modem bereitstellen. Die Funktionsgruppe für die akustische Eingabe stellt die Möglichkeit bereit, akustische Eingaben zu empfangen, diese zu digitalisieren und zu komprimieren sowie im Datenspeicher 87 zu speichern. Die Funktion zur akustischen Ausgabe realisiert im wesentlichen die Umkehrung der Funktion der akustischen Eingabe; aus einem digitalisierten komprimierten Signal wird ein akustisches Ausgabesignal rekonstruiert. Die Sprachsynthesefunktionsgruppe stellt Mittel bereit, aus einem ASCII-Text eine verständliche Sprache zu erzeugen. Die Spracherkennungsfunktionsgruppe liefert die Möglichkeit, früher "gelernte" Worte zu erkennen. Die Funktionsgruppe zur asynchronen Kommunikation bietet die Möglichkeit, unter Benutzung normaler asynchroner Protokolle Daten über eine Telefonleitung wie etwa die Leitungen 34 und 35 zu senden und zu empfangen.
Zusätzlich zu den oben erwähnten Telefonleitungen 34 und 35 sind noch ein Telefon 28, ein Mikrofon 29 und ein Lautsprecher 31 vorhanden. Das Mikrofon 29 ermöglicht es einem Anwender akustische Information in das Digitalverarbeitungssystem einzugeben, während man über dem Lautsprecher 31 akustische Ausgangssignale hören kann. Die Leitung 32 hat eine Anzeige für den Ein-Aus-Gabel um den Status des Telefons 28 anzuzeigen. Wenn der Handapparat des Telefons 28 vom Haken genommen wird, schließt sich das Relais 27; damit kann ein Telefonruf auf der Leitung 34 eingeleitet werden. Die Telefonleitungsschnittstelle 26 ist eine Schnittstelle für die Telefonleitung 34, während die Telefonleitungsschnittstelle 25 eine Schnittstelle für die Telefonleitung 35 ist. Die Telefonleitungsschnittstellen 25 und 26 werden nicht als Hardware-Betriebsmittel des Signalverarbeitungssystems so eingeordnet.
Die letzten beiden Hardware-Betriebsmittel sind die Anschlüsse 15 und 17. Der Anschluß 15 enthält einen Sender 18 und einen Empfänger 19, und in ähnlicher Weise enthält Anschluß 17 einen Sender 32 und einen Empfänger 33. Das Telefon 28, das Mikrofon 29, der Lautsprecher 31 und die Telefonleitungen 34 und 35 arbeiten über die Anschlüsse 15 und 17 im Multiplexbetrieb; diese wiederum arbeiten mit einem einzelnen Paar von A/D- und D/A- Wandlern im Multiplexbetrieb. Die A/D- und D/A-Wandlung bildet keinen Teil dieser Erfindung und wird im weiteren nicht diskutiert. Die Anschlüsse 15 und 17 sind entweder durch die Partition 12 oder durch die Partition 13 zugänglich. Zusätzlich können beide Partitionen auf den gleichen Anschluß zugreifen.
Zusätzlich zu den bisher erwähnten Hardware-Betriebsmitteln gibt es drei Interrupt-Betriebsmittel, die eine Anwendung benutzen kann. Die ersten zwei Interrupt-Betriebsmittel sind Einwahlinterrupts auf den Leitungen 34 bzw. 35. Das dritte Interrupt-Betriebsmittel ist der Telefon-Handapparat-Ein-Aus-Gabel der durch die Leitung 32 bereitgestellt wird.
Fig. 3 zeigt in Form vereinfachter Funktionsblöcke den Fluß der Befehle und der Schnittstelle. Die Anwendung 10 steht über der Programmschnittstelle 11 mit dem Treiber 41, dem Implementationscode 42 und dem Hardwareinterruptrouter 43 in Wechselwirkung; diese befinden sich alle im Hauptrechnersystem 12. Die Hardwareschnittstelle 44 bildet die Grenze zwischen dem Hauptrechnersystem 12 und dem Signalverarbeitungssystem 50. Anwendungsbefehle enden in Partition 24 des Befehlsspeichers 21, während die Interrupts in Partition 24 ihren Ursprung haben. Die Partition 24 enthält das Signalprozessor-Steuerprogramm. Dieses Steuerprogramm verwaltet den Befehlsspeicher 21 in den Partitionen 12, 13 und 14 und erlaubt, daß der Signalverarbeitungscode in den Partitionen 12, 13 und 14 parallel läuft, wobei die Betriebsmittel des Signalverarbeitungssystems 50 gemeinsam benutzt werden. Der Befehls- und Interruptfluß, der die Programmschnittstelle 11 definiert, wird jetzt unter Bezugnahme auf Fig. 3 und Fig. 4 ausführlicher erklärt.
Fig. 4 stellt den Befehlsfluß von der Anwendung 10 über die Schnittstelle 11 durch den Hauptrechner 12 und zum Signalverarbeitungssystem 50 ausführlicher dar. Die Befehle, die von der Anwendung 10 zur Schnittstelle 11 geleitet werden, enthalten zwei Arten der Identifikation. Die erste vorgesehene Identifikationsart ist die zu verwendende Funktionsgruppe, und diese Identifikation wählt den geeigneten Steuerblock 51 aus, der seinerseits auf den Implementationscode 42 zugreift. Die zweite Identifikationsart bestimmt der jeweiligen Befehle innerhalb einer gegebenen Funktionsgruppe. Der Treiber 41 nimmt diese Befehle und leitet sie weiter zu den geeigneten Plätzen im Implementationscode 42. Die Steuerblockauswahlfunktion, die Teil der Befehlseingabe zur Schnittstelle 11 und zum Treiber 41 ist, identifiziert einen speziellen Steuerblock 51. Dieser Steuerblock 51 enthält einen Zeigerblock 71, der auf den Anfang des Befehlsvektorblockes 52 zeigt. Die im Befehl enthaltene Befehlscodeinformation wird über Leitung 72 ausgegeben. Zusammen mit der Zeigerinformation vom Zeigerblock 71 wird vom Befehlscode die spezielle Stelle im Befehlsvektor 52 gezeigt oder indiziert, zu der dieser Befehl gehört. Nach der Ausführung zeigt der Befehlsvektor 52 auf einen speziellen Teils des Implementationscodes im Befehlsprozessor 53. Ist der spezielle Teil des geforderten Codes gefunden, dann übergibt der Treiber 41 die Steuerung an diesen Kommandoprozessor 53, der diesen erforderlichen Code enthält. Tatsächlich realisiert der Kommandovektor 52 zusammen mit dem über Leitung 72 ausgegebenen Kommandocode und dem Zeigerblock 71 eine Adressierungsfunktion. Der Befehlsprozessor 53 führt dann den speziellen Befehl aus der von der Anwendung 10 an das Hardwaresystem 50 ausgegeben wurde.
Fig. 5 detailliert den Interruptfluß vom Signalverarbeitungssystem 50 zurück über den Hauptrechner 12 zur Schnittstelle 11 und dann zur Anwendungsinterruptroutine 61 in der Anwendung 10. Vom Signalverarbeitungssystem 50 wird ein Interrupt erzeugt und über die Hardwareschnittstelle 44 und Leitung 73 an den Hardwareinterruptrouter 43 ausgegeben. Der Interrupt enthält sowohl Information zur Partition als auch Information zur Art des Interrupts. Die Information zur Partition wird zur Identifikation des Steuerblockes 66 benutzt, der den Zeiger 72 enthält, der auf den Anfangspunkt des Interruptvektors 67 zeigt. Die Interruptart wird über die Leitung 75 eingegeben. Zusammen mit dem Zeiger 72 wird auf den richtigen Punkt im Interruptvektorblock 67 zugegriffen. Nach der Ausführung zeigt der Interruptvektor 67 auf den Eintrittspunkt im Interrupthandler 68. Der Hardwareinterruptrouter 43 bringt dann den Interrupt zum Interrupthandler 68. Dann arbeitet der Interrupthandler 68 und bringt den Interrupt über den Anwendungsinterruptvektor 64 zur Anwendungsinterruptroutine 61. Die auf Leitung 63 zur Anwendungsinterruptroutine 61 gebrachte Information enthält Angaben darüber, welcher Interrupt kommt und übergibt der Anwendung 10 die Steuerung, um den Interrupt zu verarbeiten. Nachdem die Steuerung an die Anwendung 10 übergeben wurde, wird von der Anwendung 10 ein Lesestatuskommando ausgegeben. Die Lesestatusinformation wird dann über die Leitung 62 vom Interruptstatusblock 65 an die Anwendungsinterruptroutine 61 gegeben. Dieses Signal liefert mehr Information bezüglich des gerade gesendeten Interrupts und informiert die Anwendungsinterruptroutine 61 über alle Interrupts, die seit dem vorhergehenden Lesestatuskommando stattgefunden haben. Der Interruptstatusblock 65 wird vom Interrupthandler 68 jedesmal, wenn der Interrupthandler 68 vom Hardwareinterruptrouter 43 angesprochen wurde, auf den neuesten Stand gebracht.
Eine Funktionsgruppe wie die Telefon- oder die Leitungsüberwachungsgruppe enthält zwei Programmdateien. Eine Datei ist für das Hauptrechnersystem 12, während die andere Datei für das Signalverarbeitungssystem 50 ist. Wenn eine Funktionsgruppe aktiviert wird, werden beide Dateien in den Speicher des Hauptrechners 12 geladen und wird der Signalverarbeitungscode in den Befehlsspeicher 21 geladen. Dieses Laden ist im wesentlichen eine Bewegung von Speicher zu Speicher, die durch die Basispartition 14 ausgeführt wird. Dieses Laden kann ausgeführt werden, während eine der beiden anderen Partitionen 12 oder 13 arbeitet.
Irgendein Anwendungsprogramm, das irgendwelche verfügbaren Betriebsmittel des Signalverarbeitungssystems 50 benötigt, muß sich mit einer OPEN-Funktion um Zugriff zu diesen Betriebsmitteln bemühen. Das Signalverarbeitungssystem 50 erlaubt einen begrenzten Grad an Parallelität, d. h. eine begrenzte Zahl von Anwendungen darf gleichzeitig auf das System zugreifen. Bei der bevorzugten Realisierung dürfen vier Anwendungen gleichzeitig laufen. Mit dieser Begrenzung können zum Beispiel zwei Anwendungen die Partitionen 12 und 13 des Befehlsspeichers 21 unabhängig nutzen. Dies kann vorkommen, wenn die Partition 12 benutzt wird, um einen Telefonruf einzuleiten, und neue gleichzeitig die Partition 13 zur Spracherkennung verwendet wird. Zusätzlich können ein oder zwei Anwendungen die beiden Einwählinterrupts auf den Leitungen 34 und 35 gleichzeitig benutzen. Wenn die Zahl der zulässigen gleichzeitigen Anwendungen nicht überschritten wird, dann ist die OPEN-Funktion erfolgreich, und die Identifikation (ID) eines Betriebsmittelsteuerblockes (RCB) wird an die Anwendung zurückgegeben, die die Betriebsmittel sucht. Der RCB wird benutzt, um die Anwendung zu identifizieren und anzuzeigen, welche Betriebsmittel durch die Anwendung gefordert werden. Irgendeine Betriebsmittelanforderung wird realisiert, indem der RCB dem Signalverarbeitungssystem 50 übergeben wird. Analog zum Betriebsmittelsteuerblock gibt es einen Systemsteuerblock (SCB), der einen Hinweis liefert, ob ein gegebenes Betriebsmittel irgendeinem anderen RCB zugeordnet wurde oder ob das Betriebsmittel noch für eine Zuweisung verfügbar ist.
Drei Funktionen werden vom Signalverarbeitungssystem 50 bereitgestellt, damit eine Anwendung die Hardware- oder Interruptbetriebsmittel erhalten kann, die zur Ausführung notwendig sind. Die erste Funktion ist ein "Lesen Hardware" (READ HDW). Die Funktion READ HDW enthält zwei Operanden, die zugehörige Hardware und die verfügbaren Hardware-Operanden. Diese zwei Operanden zeigen jeweils an, welche Betriebsmittel der fordernde RCB besitzt und welche Betriebsmittel gegenwärtig verfügbar sind, d. h., daß kein RCB dieses Systembetriebsmittel besitzt. Diese letzte Information wird vom Systemsteuerblock geliefert. Die Funktion READ HDW enthält auch die Identifikationsnummer des anfordernden RCB als einen Operanden. Die zweite, vom Signalverarbeitungssystem 50 bereitgestellte Funktion ist eine Funktion "Beanspruche Hardware" (CLAIM HDW), die einen RCB als ersten Operanden und einen Hardware-Operanden enthält, durch den die Anwendung die Betriebsmittel in Besitz nimmt, die vom RCB der Anwendung gefordert werden. Die fordernde Anwendung erhält diese Betriebsmittel, selbst wenn sie anderen RCBs entzogen werden müssen. Jeder RCB, dem auf diese Weise ein Systemelement entzogen wurde, erhält einen Interrupt "Hardware entzogen", um ihn vor diesem Ereignis zu warnen. Der RCB, dem ein Systemelement entzogen wurde, gibt alle seine anderen Hardware-Betriebsmittel an das Signalverarbeitungssystem 50 zurück.
In dieser Umgebung darf ein Anwender eine Anwendung starten, die die gegenwärtig von einer anderen Anwendung benutzten Betriebsmittel beansprucht. Die neu gestartete Anwendung benutzt die Funktion READ HDW, um den Anwender vor diesem Anspruch zu warnen. Wenn sich der Anwender für eine Fortsetzung entscheidet, wird die Funktion CLAIM HDW benutzt, um mit Hilfe des identifizierten RCB der Anwendung die geforderten Betriebsmittel zu bieten. Man beachte, daß die fordernde Anwendung erst dann Betriebsmittel verwenden kann, wenn diese durch die Funktion CLAIM HDW beansprucht wurden.
Die letzte Funktion, die vom Signalverarbeitungssystem 50 für die Zuweisung und Steuerung von RCBs bereitgestellt wird, ist die Funktion "Hardware frei" (FREE HDW). Diese Funktion ermöglicht es, daß eine Anwendung irgendwelche oder alle Betriebsmittel an das Signalverarbeitungssystem 50 zur Verwendung durch andere Anwendungen zurückgibt. Die Funktion FREE HDW identifiziert den RCB, der die Betriebsmittel freigibt, und spezifiziert, welche Betriebsmittel freigegeben werden. Wenn eine Anwendung endet, gibt sie ihren Anspruch dem Signalverarbeitungssystem 50 mit einer Funktion CLOSE frei. Diese Funktion gibt den RCB an das Signalverarbeitungssystem 50 zurück und setzt irgendwelche Hardware-Betriebsmittel frei, die dem RCB noch gehören können. Auf diese Weise werden alle Betriebsmittel die diesem RCB zugeordnet waren, wieder für das Signalverarbeitungssystem 50 und andere Anwendungen verfügbar. Das Freigeben der Betriebsmittel umfaßt auch die Interrupt-Betriebsmittel.
Die Arbeit mit den Funktionsgruppen CLAIM HDW, FREE HDW und READ HDW ist in Fig. 6 dargestellt. Dieses Flußdiagramm setzt voraus, daß der RCB 1 Betriebsmittel fordert, die gegenwärtig dem RCB 2 gehören. RCB 1 will vor RCB 2 an die Reihe kommen. In Schritt 81 wird bestimmt, ob irgendeine der Betriebsmittel, die von RCB 1 gefordert werden, nicht verfügbar ist. Wenn alle Betriebsmittel verfügbar sind, dann werden die geforderten Betriebsmittel RCB 1 zugewiesen. Wenn jedoch einzelne Betriebsmittel nicht verfügbar sind, dann wird in Schritt 82 bestimmt, ob die benötigten Betriebsmittel RCB 2 gehören oder nicht. Wenn dies nicht der Fall ist, dann verzweigt das Flußdiagramm zum Schritt 85, wo alle anderen gegenwärtig aktiven RCBs geprüft werden. Wenn jedoch die geforderten Betriebsmittel RCB 2 gehören, dann werden, wie in Schritt 83 angezeigt, alle Betriebsmittel von RCB 2 an das System zurückgegeben. Im Schritt 84 wird ein Interrupt "Hardware entzogen" erzeugt für die Anwendung, bei der vom RCB 2 in Schritt 83 ein Systemelement genommen wurde. Nachdem, wie in Schritt 85 angezeigt, alle anderen RCBs geprüft wurden, werden die angeforderten Betriebsmittel RCB 1 zur Arbeit mit der anfordernden Anwendung zugeordnet.

Claims

1. Signalverarbeitungssystem (50), das folgendes aufweist:

eine Mehrzahl von Systembetriebsmitteln (12, 13, 14, 15, 17, 34, 35, 28, 29, 31),

eine Mehrzahl von Anwendungsprogrammen (10), die eine gleichläufige Verwendung zumindest eines aus der Mehrzahl von Systembetriebsmitteln erfordern, wobei ein erstes Anwendungsprogramm (10) unter Verwendung des zumindest einem aus der Mehrzahl von Systembetriebsmitteln (12, 13, 14, 15, 17) abläuft,

Mittel zum Entziehen des zumindest einen aus der Mehrzahl von Systembetriebsmitteln (12, 13, 14, 15, 17) aus dem Anwendungsprogramm (10, um eine Ausführung eins zweiten Anwendungsprogramms (10) unter Verwendung des zumindest einem aus der Mehrzahl von Systembetriebsmitteln zu ermöglichen, dadurch gekennzeichnet, daß dieses ferner folgendes aufweist:

ein Mittel (RCB) zum Identifizieren, welche aus der Mehrzahl von Systembetriebsmitteln zum Ausführen jedes aus der Mehrzahl von Anwendungsprogrammen (10) erforderlich sind,

ein Mittel (SCB) zum Erfassen eines Konflikts für die Mehrzahl von Systembetriebsmitteln in der Mehrzahl von Anwendungsprogramm (10),

Mittel (READ-HDW) zum Warnen des Benutzers vor der Verhinderung durch die erste Anwendung (10) des zumindest einen aus der Mehrzahl von Betriebsmitteln, die auch von der zweiten Anwendung gefordert sind und Mittel (CLAIM HDW) zum Ergreifen der geforderten Betriebsmittel, falls sich der Benutzer entscheidet, mit der zweiten Anwendung fortzufahren.

2. Signalverarbeitungssystem (50) nach Anspruch 1, dadurch gekennzeichnet, daß das Mittel (RCB) zum Identifizieren einen Betriebsmittelsteuerblock aufweist, wobei der Betriebsmittelsteuerblock einen ersten Teil zum Identifizieren eines Anwendungsprogramms und einen zweiten Teil zum Identifizieren der Systembetriebsmittel (12, 13, 14, 15, 17, 34, 35) aufweist, die von dem Anwendungsprogramm (10) gefordert sind.

3. Signalverarbeitungssystem (50) nach Anspruch 2, dadurch gekennzeichnet, daß das Erfassungsmittel (SCB) einen Systemsteuerblock aufweist, der Informationen darüber enthält, welches aus der Mehrzahl von Systembetriebsmitteln einem oder mehreren Betriebsmittelsteuerblöcken zugeordnet wurden.

4. Signalverarbeitungssystem (50) nach Anspruch 3, dadurch gekennzeichnet, daß dieser ferner Mittel aufweist, um den Betriebsmittelsteuerblock mit dem Systemsteuerblock zu vergleichen, wobei die Identifizierung identischer Betriebsmittel sowohl in dem Systemsteuerblock als auch in dem Betriebsmittelsteuerblock eine Anzeige eines Betriebsmittelkonflikts liefert.

5. Signalverarbeitungssystem (50) nach Anspruch 1, dadurch gekennzeichnet, daß dieses ferner Mittel aufweist, um eine Ausführung des ersten Anwenderprogramms (10) bis zu einem Abschluß des zweiten Anwendungsprogramms auszusetzen.

6. Signalverarbeitungssystem (50) nach Anspruch 1, dadurch gekennzeichnet, daß die Mehrzahl von Systembetriebsmitteln eine Mehrzahl von Hardware-Betriebsmitteln und eine Mehrzahl von Hardware-Betriebsmitteln und eine Mehrzahl von Unterbrechungsbetriebsmitteln aufweist.

7. Signalverarbeitungssystem (50) nach Anspruch 6, dadurch gekennzeichnet, daß die Mehrzahl von Unterbrechungsbetriebsmitteln zumindest eine Rufunterbrechung und eine Telefon Ein/Aus-Unterbrechung aufweist.

8. Signalverarbeitungssystem (50) nach Anspruch 6, dadurch gekennzeichnet, daß die Mehrzahl von Hardware-Betriebsmitteln zumindest eine Telefonleitung, ein Telefon, ein Mikrofon und einen Lautsprecher aufweist.

9. Signalverarbeitungssystem (50) nach Anspruch 8, dadurch gekennzeichnet, daß dieses ferner eine Mehrzahl von Anschlüssen (15, 17) aufweist, die mit der zumindest einen Telefonleitung (34, 35) und mit dem Telefon, Mikrofon (29) und Lautsprecher (31) verbunden sind.

10. Signalverarbeitungssystem nach Anspruch 6, dadurch gekennzeichnet, daß die Mehrzahl von Hardware-Betriebsmitteln zumindest zwei Partitionen (12, 13) in einem Befehlsspeicher (21) aufweist, wobei eine erste (12) der Partitionen Funktionssätze enthält, um Sprech- und Leitungsüberwachungsfunktionen auszuüben und eine sprech- und Leitungsüberwachungsfunktionen auszuüben und eine zweite Partition (13) Funktionssätze enthält, um einen Spracheingang und -Ausgang, Sprachsynthese, Spracherkennung und eine asynchrone Übertragung zu liefern.