DE60005051T2

DE60005051T2 - Auf programmfäden basiertes verfahren und systeme zur verwendung der freien verarbeitungsleistung eines oder mehrerer vernetzten rechner um komplizierte wissenschaftliche probleme zu lösen

Info

Publication number: DE60005051T2
Application number: DE60005051T
Authority: DE
Inventors: Christopher E. Keefer; Stephane Murphy; Joseph D. Simpkins; Sidney Stanley Young
Original assignee: Glaxo Group Ltd
Current assignee: Glaxo Group Ltd
Priority date: 1999-11-29
Filing date: 2000-11-29
Publication date: 2004-07-08
Anticipated expiration: 2020-11-30
Also published as: CA2396442A1; ATE249068T1; DE60005051D1; AU1807801A; EP1234230A2; ES2206329T3; WO2001038973A2; JP2003515807A; WO2001038973A3; EP1234230B1

Description

Technischer Bereich
Die vorliegende Erfindung betrifft Verfahren und Systeme zum Ausnutzen der freien Rechenleistung eines oder mehrerer vernetzter Computer zum Lösen komplexer wissenschaftlicher Probleme. Die vorliegende Erfindung betrifft insbesondere Thread-basierte Verfahren und Systeme zum Ausnutzen der freien Rechenleistung eines oder mehrerer vernetzter Computer zum Lösen komplexer wissenschaftlicher Probleme.
Hintergrundtechnik
Viele mittlere bis große Gesellschaften oder Unternehmen verfügen über eine große Anzahl von Arbeitsplatzrechnern (Desktop-Computern), die über ein oder mehrere Netzwerke miteinander verbunden sind. Diese Computer werden während einer wesentlichen Zeitdauer nicht genutzt. Beispielsweise können solche Maschinen in der Nacht, an Wochenenden und während Angestellte anderweitig beschäftigt sind, frei oder ungenutzt sein. Eine kürzliche Untersuchung zeigt, daß Arbeitsplatzrechner für weniger als 5% der Zeit genutzt werden. Auch Server sind typischerweise über 90% der Zeit ungenutzt. Hinsichtlich der ungenutzten Rechenleistung freier oder ungenutzter Arbeitsplatzrechner sind Verfahren und Systeme zum Ausnutzen dieser freien Rechnerleistung zum Lösen komplexer Probleme entwickelt worden.
Beispielsweise wird im US-Patent Nr. 6 112 225 von Kraft et al. ein Task- oder Aufgabenverteilungsverarbei tungssystem und -verfahren zum Zugreifen auf Computer zum Ausführen von Rechenaufgaben während der freien oder Leerlaufzeit beschrieben. Im von Kraft et al. beschriebenen System sind Peripherierechner erforderlich, um ein Leerlaufzeitaktivierungsprogramm von einem Koordinierungscomputer herunterzuladen. Das Leerlaufzeitaktivierungsprogramm kann einen Bildschirmschoner aufweisen, der basierend auf einer Verarbeitungslast oder einer vorgegebenen Zeitdauer, seitdem der Benutzer zuletzt auf die Tastatur zugegriffen hat, bestimmt, ob der Peripherierechner sich im Leerlaufzustand befindet. Es ist unerwünscht, wenn Benutzer zum Herunterladen eines Leerlaufzeitaktivierungsprogramms benötigt werden, weil dieser Vorgang für jeden Computer ausgeführt werden muß, der an einer kombinierten Aufgabe teilnehmen soll. Weiterhin verbraucht ein ausgeführtes Programm, welches die Verarbeitungslast oder die Zeit, seit der auf die Tastatur zugegriffen wurde, mißt, Rechenzyklen auf den Peripherierechnern und verschwendet auf dieses Weise Leerlaufzeit, die anderenfalls um eine kombinierte Aufgabe auszuführen genutzt werden könnte.
Im US-Patent Nr. 5 031 089 von Liu et al. wird ein dynamisches Ressourcenzuweisungsschema für verteilte heterogene Computersysteme beschrieben. Im Patent von Liu et al. weisen mehrere gleichschichtige oder Peer-Knoten eine Logik zum Berechnen und Sichern eines Arbeitslastwertes auf, der die Anzahl von Aufträgen in der Warteschlange des Knotens anzeigt. Jeder Knoten weist eine Logik zum Übertragen von Aufgaben zu anderen Peer-Knoten auf. Schließlich weist jeder Knoten eine Logik auf, die nach Abschluß jedes Auftrags aktiviert wird und durch die der Arbeitslastwert des eigenen Knotens geprüft wird und die Arbeitslastwerte aller anderen Peer-Knoten abgefragt werden. Wenn der Arbeitslastwert des eigenen Knotens niedrig ist und die Arbeitslastwerte der anderen Knoten hoch sind, wird der prüfende oder abfragende Knoten Aufgaben von einem anderen überlasteten Knoten ziehen. Obwohl durch das System von Liu et al. ein Lastausgleich zwischen Peer-Computern erreicht werden kann, kann ein solches System das die Peer-Computer verbindende Netzwerk mit Verkehr zwischen Knoten überlasten, die kontinuierlich versuchen, ihre Lasten auszugleichen. Ein solcher Verkehr könnte das Netzwerk verstopfen und wäre für den Benutzer nicht transparent. Daher ist das im Patent von Liu et al. beschriebene System möglicherweise in einem Netzwerk unerwünscht, in dem Computer zum Lösen eines Problems durch eine verteilte Verarbeitung auch von Endbenutzern genutzt werden.
In einem großen Unternehmen, z.B. in einer pharmazeutischen Herstellerfirma, benutzen Endbenutzer ihre Computer möglicherweise für Email, Web-Browsing, Textverarbeitung und andere Aufgaben. Wenn ein oder mehrere Computer des mit diesen Computern verbundenen Netzwerks ein komplexes wissenschaftliches Problem lösen, wobei ein peer-basierter Lastausgleich verwendet wird, kann der Verkehr, der erforderlich ist, um den peer-basierten Lastausgleich zu implementieren, das Netzwerk überlasten und Kommunikationen zu und von (Computern stören, die nicht frei oder ungenutzt sind. Daher ist das im Patent von Liu et al. beschriebene System möglicherweise nur für verteilte Computer geeignet, die zum Lösen eines komplexen Problems freigegeben sind.
Hinsichtlich der mit herkömmlichen verteilten Rechenalgorithmen verbundenen Schwierigkeiten besteht Bedarf für Verfahren und Systeme zum Ausnutzen der freien Rechenleistung vernetzter Computer zum Lösen komplexer Probleme auf eine Weise, gemäß der der Einfluß auf Endbenutzer minimiert wird.
Kurze Beschreibung der Erfindung
Gemäß einem Aspekt wird durch die vorliegende Erfindung ein Thread-basiertes System zum Lösen komplexer wissenschaftlicher Probleme bereitgestellt. Ein solches System weist einen Client auf, der Aufgaben von einem mit einem komplexen wissenschaftlichen Problem in Beziehung stehenden Server zieht. Der Client weist einen Computercode zum Starten eines ersten Thread zum Ziehen einer Auftragsbeschreibung vom Server und eines zweiten Thread zum Ziehen von Daten vom Server auf. Der Client ermöglicht es dem Betriebssystem, die Ausführung des ersten und des zweiten Thread automatisch zu planen/schedulen. Der Ausdruck "freie Threads" ("Idle-Threads") bezeichnet hierin Threads, denen eine niedrigere Priorität zugeordnet ist als Benutzer-Threads. Benutzer-Threads sind solche Threads, die durch Benutzerprogramme geplant werden, z.B. Textverarbeitungsprogramme, Email-Programme, usw. Der Ausdruck "Thread" bezeichnet hierin Ausführungs-Threads, die Ablaufinstanzen von Programmen sind.
Das Thread-basierte System wird gemäß Ausführungsformen der vorliegenden Erfindung vorzugsweise durch Netzwerk-Computer zum Lösen einer komplexen wissenschaftlichen Aufgabe verwendet. Weil der Code bei den Clients automatisch ausgeführt wird, wenn das Client-Betriebssystem einen freien der abarbeitungsbereiten Ausführungs-Thread plant, wird der Einfluß auf den Benutzer minimiert. Außerdem bearbeitet ein solches System, wie nachstehend ausführlicher beschrieben wird, vorzugsweise eine komplexe Aufgabe, die in kleine Teile geteilt ist, so daß die über das Netzwerk übertragenen Daten zum Ausführen der Aufgabe minimiert sind und die durch jeden Client ausgeführte Aufgabe maximal ist. Rechenintensive Aufgaben, die erfindungsgemäß durch Clients ausgeführt werden können, sind beispielsweise: Bestimmen dreidimensionaler Molekülstrukturen und Bestimmen anderer physikalischer Eigenschaften von Molekülen. In einem solchen System können die Clients ein Molekül oder einen Molekülsatz von einer Molekülsammlung ziehen, auf die der Server zugreifen kann. Die Clients können dann die zum Bestimmen der Eigenschaften der Moleküle erforderlichen komplexen Berechnungen ausführen. Die Clients übermitteln anschließend die Rechenergebnisse an den Server. Weil Moleküldarstellungen typischerweise kurz sind, sind die über das Netzwerk übertragenen Daten minimiert. Außerdem führen, weil die zum Bestimmen dreidimensionaler Eigenschaften und anderer Eigenschaften von Molekülen erforderlichen Verarbeitungen rechenintensiv sind, die Clients einen großen Verarbeitungsaufwand aus. Dadurch werden die Ziele zum Minimieren des Netzwerkverkehrs und zum Maximieren der Arbeitsleistung durch Clients erreicht.
Daher ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System zum Ausnutzen der freien Rechenleistung eines oder mehrerer vernetzter Computer zum Lösen eines komplexen wissenschaftlichen Problems bereitzustellen, durch die der Einfluß auf den Benutzer und das Benutzernetzwerk minimiert wird.
Einige Merkmale der vorliegenden Erfindung wurden vorstehend dargestellt, und andere Aufgaben und Vorteile werden nachstehend im Verlauf der Beschreibung in Verbindung mit den beigefügten Zeichnungen deutlich.
Kurze Beschreibung der Zeichnungen
Nachstehend werden bevorzugte Ausführungsformen der Erfindung unter Bezug auf die beigefügten Zeichnungen verdeutlicht; es zeigen:
1 ein Blockdiagramm zum Darstellen einer exemplarischen Betriebsumgebung für Ausführungsformen der vorliegenden Erfindung;
2 ein schematisches Diagramm eines Threadbasierten Systems zum Lösen komplexer wissenschaftlicher Probleme gemäß einer Ausführungsform der vorliegenden Erfindung;
3 ein Ablaufdiagramm zum Darstellen exemplarischer Schritte, die durch einen Client ausgeführt werden, der einen Auftrag von einem Server zieht und die gemäß dem Auftrag erforderliche Aufgabe unter Verwendung von Threads ausführt, die durch das Betriebssystem gemäß einer Ausführungsform der vorliegenden Erfindung automatisch geplant werden; und
4 ein Blockdiagramm zum Darstellen des durch ein in Ausführungsformen der vorliegenden Erfindung verwendetes Betriebssystem automatischen Planen von Threads zum Lösen komplexer wissenschaftlicher Probleme.
Ausführliche Beschreibung der Erfindung
Exemplarische Betriebsumgebung
Die vorliegende Erfindung ist in den Zeichnungen, in denen ähnliche Bezugszeichen ähnliche Elemente bezeichnen, in einer geeigneten Rechenumgebung implementiert. Obwohl dies nicht erforderlich ist, wird die Erfindung allgemein in Verbindung mit auf einem Computer ausführbaren Befehlen beschrieben, z.B. in Verbindung mit Programmmodulen, die auf einem Personalcomputer ausgeführt werden. Programmmodule weisen allgemein Routinen, Programme, Objekte, Komponenten, Datenstrukturen, usw. auf, die spezifische Aufgaben ausführen oder spezifische abstrakte Datentypen implementieren. Außerdem ist für Fachleute ersichtlich, daß die Erfindung auch mit anderen Computersystemkonfigurationen realisierbar ist, z.B. mit handgehaltenen Geräten, Mehrprozessorsystemen, mikroprozessor-basierter oder programmierbarer Konsum- oder Unterhaltungselektronik, Netzwerk-PCs, Minicomputern, Großrechnern, und ähnlichen. Die Erfindung kann außerdem in verteilten Rechenumgebungen realisiert werden, in denen Aufgaben durch entfernte oder abgesetzte Verarbeitungsvorrichtun gen ausgeführt werden, die über ein Kommunikationsnetz verknüpft sind. In einer verteilten Rechenumgebung können Programmmodule sowohl in lokalen als auch in entfernten oder abgesetzten Speichervorrichtungen angeordnet sein.
Gemäß 1 weist ein exemplarisches System zum Implementieren der Erfindung eine Mehrzweck-Rechenvorrichtung in der Form eines herkömmlichen Personalcomputers 20 auf, der eine Verarbeitungseinheit 21, einen Systemspeicher 22 und einen Systembus 23 aufweist, der verschiedene Systemkomponenten, einschließlich des Systemspeichers, mit der Verarbeitungseinheit 21 verbindet. Der Systembus 23 kann unter Verwendung verschiedenartiger Busarchitekturen einen beliebigen von mehreren Busstrukturtypen aufweisen, z.B. einen Speicherbus oder einen Speichercontroller, einen Peripheriebus und einen lokalen Bus. Der Systemspeicher weist einen Festwertspeicher (ROM ) 24 und einen Direktzugriffsspeicher (RAM) 25 auf. Ein Basis-Ein-/Ausgabesystem (BIOS) 26, das die Basisroutinen aufweist, die dazu beitragen, z.B. während des Hochfahrens Information zwischen Elementen im Personalcomputer 20 zu übertragen, ist im ROM-Speicher 24 gespeichert. Der Personalcomputer 20 weist ferner auf: ein Festplattenlaufwerk 27 zum Lesen und Schreiben von Daten von einer oder auf eine Festplatte (nicht dargestellt), ein Magnetplattenlaufwerk 28 zum Lesen und Schreiben von Daten von einer oder auf eine entfernbare Magnetplatte 29 und ein optisches Plattenlaufwerk 30 zum Lesen und Schreiben von Daten von einer oder auf eine entfernbare optische Platte 31, z.B. eine CD-ROM oder ein anderes optisches Medium.
Das Festplattenlaufwerk 27, das Magnetplattenlaufwerk 28 und das optische Plattenlaufwerk 30 sind durch eine Festplattenlaufwerkschnittstelle 32, eine Magnetplattenlaufwerkschnittstelle 33 bzw. eine Schnittstelle 34 des optischen Plattenlaufwerks mit dem Systembus 23 verbunden. Durch die Laufwerke und ihre entsprechenden computerlesbaren Medien wird ein nichtflüchtiger Speicher für computerlesbare Befehle, Datenstrukturen, Programmmodule und andere Daten für den Personalcomputer 20 bereitgestellt. Obwohl in der hierin beschriebenen exemplarischen Umgebung ein Festplatte, eine entfernbare Magnetplatte 29 und eine entfernbare optische Platte 31 verwendet wird, ist für Fachleute ersichtlich, daß in der exemplarischen Betriebsumgebung auch andersartige computerlesbare Medien verwendbar sind, die Daten speichern können, auf die ein Computer zugreifen kann, z.B. Magnetkassetten, Flash-Speicherkarten, digitale Videoplatten, Bernoulli-Kassetten, RAM-Speicher, ROM-Speicher und ähnliche.
Auf der Festplatte, der Magnetplatte 20, der optischen Platte 31, im ROM-Speicher 24 oder im RAM-Speicher 25 können mehrere Programmmodule gespeichert sein, z.B. ein Betriebssystem 35, ein oder mehrere Anwendungsprogramme 36 oder Programmmodule 37 und Programmdaten 38. Das Betriebssystem 35 kann einen Thread-Scheduler aufweisen, der Threads gemäß durch Benutzerprogramme gesetzten Thread-Prioritätswerten oder -pegeln automatisch plant und einteilt. Ein Benutzer kann über Eingabevorrichtungen, z.B. eine Tastatur 40 und eine Zeigervorrichtung 42, Befehle und Information in den Personalcomputer 20 eingeben. Andere Eingabevorrichtungen (nicht dargestellt) sind beispielsweise ein Mikrofon, ein Touch-Panel, ein Joystick, ein Game-Pad, eine Satellitenantenne, ein Scanner, und ähnliche. Diese und andere Eingabevorrichtungen sind häufig über eine mit dem Systembus verbundene serielle Schnittstelle 46 mit der Verarbeitungseinheit 21 verbunden, sie können jedoch auch über andere Schnittstellen, z.B. einen parallelen Port, einen Game-Port oder einen universellen seriellen Bus (USB) mit der Verarbeitungseinheit verbunden sein. Ein Monitor 47 oder ein andersartiges Display ist ebenfalls über eine Schnittstelle, z.B. einen Videoadapter 48, mit dem Systembus 23 verbunden. Außer einem Monitor weisen Personalcomputer typischerweise andere periphere Ausgabegeräte (nicht dargestellt) auf, z.B. Lautsprecher und Drucker.
Der Personalcomputer 20 kann unter Verwendung logischer Verbindungen in einer vernetzten Umgebung mit einem oder mehreren abgesetzten Computern verbunden sein, z.B. mit einem abgesetzten Computer 49. Der abgesetzte Computer 49 kann ein anderer Personalcomputer, ein Server, ein Router, ein Netzwerk-PC, ein Peer-Gerät oder ein gemeinsamer Netzwerkknoten sein und weist typischerweise viele oder alle der vorstehend bezüglich des Personalcomputers 20 beschriebenen Elemente auf, obwohl in 1 lediglich eine Speichervorrichtung 50 dargestellt ist. Die in 1 dargestellten logischen Verbindungen weisen ein lokales Netz (LAN) 51, ein weiträumiges Netz (WAN) 52 und ein Systemnetz (SAN) 53 auf. Die lokale und die weiträumige Netzwerkumgebung sind in Büros, unternehmensweiten Computernetzen, Intranets und im Internet üblich.
Systemnetzwerkumgebungen werden zum Verbinden von Knoten in einem verteilten Rechensystem, z.B. in einem Cluster, verwendet. Beispielsweise kann der Personalcomputer 20 in der dargestellten Ausführungsform einen ersten Knoten in einem Cluster aufweisen, und der abgesetzte Computer 49 kann einen zweiten Knoten im Cluster aufweisen. In einer solchen Umgebung ist es bevorzugt, daß der Personalcomputer 20 und der abgesetzte Computer 49 in einem gemeinsamen administrativen Bereich betrieben werden. Daher kann der Computer 49, obwohl er als "abgesetzter" Computer bezeichnet wird, auch in unmittelbarer physischer Nähe des Personalcomputers 20 angeordnet sein.
Wenn der Personalcomputer 20 in einer LAN- oder SAN-Netzwerkumgebung verwendet wird, ist der Personalcomputer 20 über die Netzwerkschnittstellenadapter 54 und 54a mit dem lokalen Netz 51 oder dem Systemnetz 53 verbunden. Die Netzwerkschnittstellenadapter 54 und 54a können Verarbeitungs einheiten 55 und 55a und eine oder mehrere Speichereinheiten 56 und 56a aufweisen.
Wenn der Personalcomputer 20 in einer WAN-Netzwerkumgebung verwendet wird, weist der Personalcomputer 20 typischerweise ein Modem 58 oder eine andere Einrichtung zum Einrichten von Kommunikationen über das WAN-Netz 52 auf. Das Modem 58, das ein internes oder ein externes Modem sein kann, ist über die serielle Schnittstelle 46 mit dem Systembus 23 verbunden. In einer vernetzten Umgebung können bezüglich des Personalcomputers 20 dargestellte Programmmodule oder Teile davon in der abgesetzten Speichervorrichtung gespeichert sein. Die dargestellten Netzwerkverbindungen sind lediglich exemplarisch, und es können andere Einrichtungen zum Einrichten von Kommunikationen zwischen den Computern verwendet werden.
2 zeigt eine Ausführungsform eines erfindungsgemäßen, Thread-basierten Systems zum Lösen komplexer wissenschaftlicher Aufgaben. In 2 weist das System mehrere Client-Knoten 200, Server-Knoten 202 und eine Auftragsdatenbank 204 auf. Die Client-Knoten 200 und die Server-Knoten 202 können ähnlich konfiguriert sein wie der in 1 dargestellte Personalcomputer 20. Die Auftragsdatenbank 204 kann auch einen Front-End-Computer aufweisen, der dem in 1 dargestellten Personalcomputer 20 ähnlich ist. In der dargestellten Ausführungsform sind Client-Knoten 200 über ein Ethernet 206 verbunden. Die vorliegende Erfindung ist jedoch nicht auf eine Verbindung von Client-Knoten über ein Ethernet beschränkt. Es kann in einer alternativen Ausführungsform eine beliebige lokale Netzwerktechnologie verwendet werden, z.B. ein Token-Ring-Netz oder ein FDDI-Netz.
Die Client-Knoten 200 weisen jeweils computerausführbare Befehle zum Ziehen von Aufgaben von Server-Knoten 202 basierend auf dem durch die Betriebssysteme der Client-Knoten 200 geplanten freien Threads auf. Die Server 202 können her kömmliche Web-Server sein, die auf Hypertext Transfer Protocoll (HTTP) GET-Anforderungen von Clients 200 ansprechen. Die Web-Server 202 können über HTTP-PUT-Anforderungen Daten von Clients 200 empfangen.
Die vorliegende Erfindung ist nicht auf das Bereitstel-len von Daten und Aufträgen für Clients unter Verwendung von Web-Servern beschränkt. Beispielsweise können die Server 202 in einer alternativen Ausführungsform File Transfer Protocol (FTP) Server sein. Weil Client-Knoten Protokolle verwenden, z.B. FTP- oder HTTP-Protokolle, die über Standard-Bibliotheken verfügbar sind, ist die Komplexität der Client-Programme reduziert.
3 zeigt exemplarische Schritte zum Implementieren des erfindungsgemäßen Verfahrens, das durch die Clients 200 beim Ziehen von Aufträgen und Daten von Servern 202 ausgeführt werden kann. Gemäß 3 beginnt in Schritt ST1 eine Verarbeitung, die einen Code zum Erzeugen eines ersten freien Thread enthält. Eine derartige Verarbeitung kann auf einen Client-Knoten geladen werden, wenn das Betriebssystem auf den Client-Knoten geladen wird. Die Verarbeitung kann automatisch gestartet werden, wenn das Betriebssystem startet oder hochgefahren wird. Weil der Code zum Ziehen von Daten vom Server auf einem freien Thread geplant wird, wird dieser Thread nicht ausgeführt, bis alle Threads mit Benutzerpriorität entweder ausgeführt werden oder schlafen. Nachstehend wird ein exemplarischer Mechanismus, durch den ein Betriebssystem Threads plant, ausführlicher beschrieben.
In Schritt ST2 wird der freie Thread durch das Betriebssystem für eine Ausführung geplant. In Schritt ST3 fragt der Client-Knoten den Server ab, um zu bestimmen, ob irgendwelche Aufträge verfügbar sind. Wenn in Schritt ST4 keine Aufträge verfügbar sind, setzt der Client-Knoten in Schritt ST4 den Prüf- oder Abfragevorgang fort, so lange der Thread für eine Ausführung geplant ist. Wenn ein Benutzer- Thread für eine Ausführung geplant wird oder der Benutzer-Thread erwacht, endet die Abfrage automatisch.
Wenn der Client-Knoten in Schritt ST4 eine Antwort vom Server empfängt, die anzeigt, daß ein Auftrag verfügbar ist, zieht der Client-Knoten anschließend in Schritt ST5 eine Auftragsbeschreibung vom Server. Wie vorstehend diskutiert wurde, kann das Ziehen einer Auftragsbeschreibung vom Server das Übertragen einer HTTP-GET-Anforderung an den Server beinhalten. In Schritt ST6 bestimmt der Client-Knoten, ob ein Auftragsprogramm, das den durch die Auftragsbeschreibung spezifizierten Auftrag ausführt, am Client-Knoten vorhanden ist. Wenn das erforderliche Programm nicht vorhanden ist, zieht der Client-Knoten in Schritt ST7 das Auftragsprogramm vom Server.
In Schritt ST8 erzeugt der Client-Knoten einen freien Thread des Betriebssystems, um das Auftragsprogramm auszuführen. Dies kann durch die folgenden Codezeilen erreicht werden, die in der main()-Funktion des auf dem ersten Thread ausgeführten Programms enthalten sein können.
Im vorstehend dargestellten Code sind die Befehle für WIN-DOWS^®-Betriebssysteme spezifische C++-Befehle. Für Fachleute ist jedoch ersichtlich, daß für andere Betriebssysteme, z.B. UNIX-basierte Betriebssysteme, ähnliche Befehle verwendbar sind. Im dargestellten Beispiel erzeugt die CreateThread()-Funktion einen Thread, der innerhalb des virtuellen Adreßraums der aufrufenden Verarbeitung ausgeführt wird. In der CreateThread()-Funktion steht ein Parameter, der die Adresse der durch den Thread auszuführenden Funktion spezifiziert. In diesem Beispiel ist dieser Parameter &RunningThreadProc. Durch SetThreadPriority wird die Priorität des Thread auf "idle" ("frei") gesetzt. Die ResumeThread()-Funktion dekrementiert einen Thread-Suspend-Zählwert. Wenn der Suspend-Zählwert auf 0 dekremetiert wurde, wird die Ausführung des Thread wiederaufgenommen. Der Grund, warum die ResumeThread-Funktion verwendet wird, besteht darin, daß der Thread in einem hängenden oder suspendierten Zustand erzeugt wurde, um zu ermöglichen, daß die Priorität gesetzt werden kann.
Nachdem der Auftragsausführungs-Thread erzeugt worden ist, wird der Thread so lange nicht ausgeführt, bis er durch das Betriebssystem geplant wird. Dies ist in Schritt ST9 in 3 dargestellt. In Schritt ST10 wird, nachdem das Betriebssystem den Auftragsausführungs-Thread geplant hat, das Auftragsprogramm ausgeführt. In Schritt ST11 zieht das Auftragsprogramm Eingabedaten vom Server. Dieser Arbeitsschritt kann durch die durch die Auftragsbeschreibung spezifizierten Eingabedaten festgelegt werden, und das Problem wird gelöst, wenn der das Auftragsprogramm enthaltende freie Thread durch das Betriebssystem geplant wird. Die Verarbeitung zur Problemlösung wird so lange fortgesetzt, bis der Auftrag abgeschlossen ist (Schritt ST13) oder ein anderer Thread mit höherer Priorität geplant wird. Wenn ein Thread mit höherer Priorität geplant wird, sichert das Betriebssystem den Kontext des freien Thread, führt den Thread mit höherer Priorität aus und springt dann zur Ausführung des freien Thread zurück. In Schritt ST14 übermittelt, nachdem der Auftrag abgeschlossen ist, das Auftragsprogramm das Ergebnis zum Server. Dies kann unter Verwendung einer HTTP- oder einer FTP-PUT-Anforderung ausgeführt werden.
Obwohl die in 3 dargestellte Ausführungsform das Planen eines ersten und eines zweiten freien Thread durch das Betriebssystem darstellt, um eine komplexe wissenschaftliche Aufgabe auszuführen, ist die vorliegende Erfindung nicht auf die Verwendung zweier freier Threads beschränkt.
Beispielsweise kann ein einzelner Thread oder mehr als zwei Threads verwendet werden. Außerdem müssen die Threads keine freien Threads sein. Für die Zwecke der vorliegenden Erfindung ist lediglich erforderlich, daß den Threads eine niedrigere Priorität zugewiesen ist als Benutzer-Threads, um den Einfluß auf Benutzer-Threads zu minimieren und zu veranlassen, daß die Threads durch das Betriebssystem automatisch geplant werden.
Daher wird, wie in 3 dargestellt, erfindungsgemäß der automatische Thread-Scheduling-Mechanismus des Betriebssystem genutzt, um das Ziehen von Auftragsdaten und Programmen vom Server, die Ausführung von Aufträgen und das Übermitteln der Ergebnisse zurück zum Server zu steuern. Weil das Planen/Scheduling unter Verwendung automatischer Scheduling-Verarbeitungen des Betriebssystems ausgeführt wird, wird der Einfluß auf den Benutzer und den Computer des Benutzers minimiert.
Automatisches Planen der Ausführung des Thread durch das Betriebssystem
Weil ein wesentliches Merkmal der Erfindung darin besteht, daß dem Betriebssystem ermöglicht wird, die Threads zum Ziehen von Aufgaben vom Server automatisch zu planen, folgt eine Diskussion eines solchen automatischen Planens/Scheduling. Die folgende Diskussion zeigt, wie ein WINDOWS^® NT-Betriebssystem Threads automatisch plant. Wie vorstehend beschrieben wurde, ist die vorliegende Erfindung je-doch nicht auf das WINDOWS^® NT-Betriebssystem beschränkt. Es können andere Betriebssysteme, z.B. LINUX^®- oder UNIX-basierte Betriebssysteme verwendet werden. Zum Implementieren der vorliegenden Erfindung kann ein beliebiges Betriebssystem verwendet werden, das einen automatischen Thread- Scheduling-Mechanismus aufweist, durch den Prioritäten zwischen Threads festgelegt werden können.
Im WINDOWS NT-Betriebssystem plant der Mikrokernel abarbeitungsbereite Threads für die Prozessorzeit basierend auf ihrer dynamischen Priorität, d.h. einer Zahl zwischen 1 und 31, die die Wichtigkeit der Aufgabe darstellt. Auf dem Prozessor läuft immer der Thread mit der höchsten Priorität, auch wenn hierfür ein Thread mit einer niedrigeren Priorität unterbrochen werden muß. Prioritäten sind hierarchisch organisiert. Jeder Pegel der Prioritätshierarchie spezifiziert einen Bereich, in dem Prioritäten mit niedrigerem Pegel variieren können:

1. Die Basisprioritätsklasse eines Prozesses/Verarbeitung spezifiziert einen Bereich für die Basispriorität des Prozesses und seiner Threads. Die Basisprioritätsklassen sind "Idle", "Normal", "High" und "Real-Time", die jeweils einen numerischen Bereich von Basisprioritäten darstellen, die sich manchmal an den Enden überlappen. Die Basisprioritätsklasse wird im Anwendungscode festgelegt. Ein verwendbarer, exemplarischer Anwendungscode zum Setzen einer Basisprioritätsklasse ist folgender:
Das Betriebssystem ändert die Basisprioritätsklasse nicht, es ändert jedoch die Basispriorität innerhalb der Klasse, um das Ansprechverhalten von Verarbeitungen auf den Benutzer zu verbessern.
2. Die Basispriorität eines Prozesses ändert sich innerhalb des durch seine Basisprioritätsklasse festgelegten Be reichs. Wenn ein Benutzer mit einem Prozeß wechselwirkt (das Prozeßfenster befindet sich im WINDOWS Stapel oben) , setzt WINDOWS^® NT die Basispriorität des Prozesses herauf, um sein Ansprechverhalten zu maximieren. Die Basispriorität eines Thread ist eine Funktion der Basispriorität des Prozesses, in dem er läuft. Mit Ausnahme der "Idle"- und "Real-Time"-Threads ändert sich die Basispriorität eines Thread nur innerhalb von +/- 2 bezüglich der Basispriorität seines Prozesses.
3. Die dynamische Priorität eines Thread ist eine Funktion seiner Basispriorität. WINDOWS^® NT stellt die dynamische Priorität von Threads innerhalb des durch seine Basispriorität festgelegten Bereichs kontinuierlich ein. Dies trägt dazu bei, das Ansprechverhalten des Systems auf Benutzer zu optimieren und die Erfordernisse der Ausführung von Systemdiensten und anderen Prozessen mit niedrigerer Priorität rasch auszugleichen.

Die folgende Tabelle zeigt Basisprioritätsklassen und entsprechende Thread-Prioritäten:
Kontext-Switches
Wie vorstehend beschrieben wurde, hält der Scheduler/Planer für jeden Prioritätspegel eine Warteschlange aus führbarer Threads bereit. Wenn ein Prozessor verfügbar wird, führt das System einen Kontext-Switch aus. Die Schritte im Kontext-Switch sind:

– Sichere den Kontext des Thread, dessen Ausführung gerade beendet wurde.
– Plaziere den Thread, dessen Ausführung gerade beendet wurde, am Ende der seiner Priorität zugeordneten Warteschlange;
– Finde die Warteschlange der höchsten Priorität, die abarbeitungsbereite Threads enthält;
– Entfernen den Thread am Anfang der Warteschlange, lade seinen Kontext und führe ihn aus.

Die typischsten Gründe für einen Kontext-Switch sind:

– Das Zeitintervall ist abgelaufen;
– Ein Thread mit höherer Priorität steht für eine Ausführung zur Verfügung;
– Ein laufender Thread muß warten;
– Wenn ein laufender Thread warten muß, wird der Rest seines Zeitintervalls zur Verfügung gestellt.

4 zeigt ein Blockdiagramm zum Darstellen des Thread-Scheduling, das bei einem Client gemäß einer Ausführungsform der vorliegenden Erfindung ausgeführt wird. In 4 weist das Betriebssystem 400 einen Thread-Scheduler 402 auf, der auf einem oder mehreren Mikroprozessoren 404 auszuführende Threads plant. Der Thread-Scheduler 402 hält mehrere Warteschlangen 406a – 406n aufrecht. Im dargestellten Beispiel enthält die Warteschlange 406a abarbeitungsbereite Threads für einen Prioritätspegel 31, d.h. für den höchsten Prioritätspegel im WINDOWS^® NT-Betriebssystem. Die Warteschlange 406b enthält Threads für den Prioritätspegel 30, der dem zweithöchsten Prioritätspegel entspricht.
Schließlich enthält die Warteschlange 406n Threads für einen niedrigeren Prioritätspegel, z.B. für freie Threads. In der Warteschlange 406n befinden sich Programme zum Ziehen von Auftragsdaten vom Server und zum Ausführen von Auftragsprogrammen.
Wie vorstehend beschrieben wurde, plant der Thread-Scheduler 402 Threads von Warteschlangen für eine höhere Priorität bevor er Threads von Warteschlangen für eine niedrigere Priorität plant. Im dargestellten Beispiel zieht der Thread-Scheduler 402 einen Thread 1 vom Anfang der Warteschlange 406a, weil dieser der Thread am Anfang der Warteschlange für die höchste Priorität ist. Alle Threads in den Warteschlangen 406a und 406b werden vor den Threads in der Warteschlange 406n ausgeführt. Weil Benutzerprozesse auf den Threads mit einer höheren Priorität geplant werden, werden die Programme zum Ziehen von Auftragsdaten vom Server und zum Ausführen der Aufträge einen minimalen Einfluß auf die Benutzer haben.
Wissenschaftliche Anwendungen
Wie vorstehend diskutiert wurde, können die erfindungsgemäßen Thread-basierten Verfahren und Systeme zum Ausnutzen der freien Rechenleistung eines oder mehrerer vernetzter Computer dazu verwendet werden, komplexe wissenschaftliche Probleme zu lösen. Bei der Lösung solcher Probleme werden die über das Netzwerk zu übertragenden Daten vorzugsweise minimiert, und die durch die Clients ausgeführten Verarbeitungen vorzugsweise maximiert. Ein repräsentatives Beispiel eines wissenschaftlichen Problems, das unter Verwendung von Ausführungsformen der vorliegenden Erfindung gelöst werden kann, ist die Bestimmung dreidimensionaler Molekülstrukturen. Beispielsweise können große pharmazeutische Unternehmen über Molekülsammlungen verfügen, die viele tausend Moleküle enthalten. Ein einzelner Computer würde zum Bestimmen der dreidimensionalen Eigenschaften all dieser Moleküle ein Jahr oder mehr benötigen. Daher ist es wünschenswert, diese Aufgabe unter Client-Computern zu teilen. Gemäß 2 kann eine Molekülsammlung in einer Auftragsdatenbasis 204 gespeichert sein. Jedes Molekül kann durch eine Zeichenfolge dargestellt sein. Client-Knoten 200 können ein einzelnes Molekül oder einen Teilsatz von Molekülen über Web-Server 202 von der Auftragsdatenbasis 204 ziehen. Nachdem die Knoten 200 die Moleküldarstellungen empfangen haben, führen die Knoten 200 komplexe Berechnungen für jedes Molekül aus. Die Ergebnisse werden dann an die Web-Server 202 zurückübertragen. Weil die Verarbeitung der Molekülsammlung auf mehrere Knoten verteilt werden kann, indem die freie Rechenkapazität dieser Knoten ausgenutzt wird, wird der zum Ausführen solcher Verarbeitungen erforderliche Zeit- und Kostenaufwand reduziert.
Eine andere repräsentative Anwendung für die erfindungsgemäßen Thread-basierten Verfahren und Systeme ist das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung. In diesem Beispiel ziehen Client-Knoten 200 Molekülbeschreibungen von der Auftragsdatenbank 204. Die Client-Knoten 200 führen dann Programme zum Berechnen von Eigenschaften, z.B. des Molekulargewichts, des Abstands zwischen Atomen, der Oberfläche, oder ob das Molekül in der Lage ist, am ein bestimmtes Protein anzudocken, aus.
Innerhalb des Schutzumfangs der vorliegenden Erfindung können verschiedene Details der Erfindung geändert werden. Außerdem dient die vorstehende Beschreibung lediglich zum Zweck der Erläuterung und soll die Erfindung nicht einschränken die durch die Patentansprüche definiert ist.

Claims

Thread-basiertes Verfahren zum Ausnutzen der freien Rechenleistung eines oder mehrerer vernetzter Computer zum Lösen eines komplexen Problems, wobei das Verfahren die Schritte aufweist: (a) Starten eines Threads auf einem Client-Computer zum Ziehen einer mit einem Teilbereich eines komplexen Problems in Beziehung stehenden Auftragsbeschreibung von einem Server; (b) Ermöglichen, daß ein Thread-Scheduler, der durch ein Betriebssystem bereitgestellt wird, das auf dem Client-Computer ausgeführt wird, den Zeitablauf für die Ausführung des Threads automatisch plant; und (c) Ziehen von Auftragsdaten vom Server und Lösen des durch die Auftragsbeschreibung spezifizierten Teilbereichs in Antwort auf vom Server empfangene Daten.
Verfahren nach Anspruch 1, wobei das Ziehen einer mit einem Teilbereich eines komplexen Problems in Beziehung stehenden Auftragsbeschreibung von einem Server das Übertragen einer Hypertext-Transfer-Protocol- (HTTP) GET-Anforderung an einen Web-Server aufweist.
Verfahren nach Anspruch 1, wobei das Ziehen einer mit einem Teilbereich eines komplexen Problems in Beziehung stehenden Auftragsbeschreibung von einem Server das Übertragen einer File-Transfer-Protocol- (FTP) GET-Anforderung an einen FTP-Server aufweist.
Verfahren nach Anspruch 1, wobei das Starten des Thread das Zuweisen einer Priorität zum Thread aufweist, die niedriger ist als eine Priorität eines Benutzer-Thread.
Verfahren nach Anspruch 4, wobei der Thread-Scheduler den Zeitablauf der Ausführung des Thread basierend auf der dem Thread zugewiesenen Priorität plant.
Verfahren nach Anspruch 1, wobei der Thread bestimmt, ob ein in der Auftragsbeschreibung spezifiziertes Auftragsprogramm auf dem Client-Computer resident ist, wobei der Thread, wenn festgestellt wird, daß das Auftragsprogramm nicht auf dem Client-Computer resident ist, das Auftragsprogramm vom Server-Computer zieht.
Verfahren nach Anspruch 6, wobei das Ziehen des Auftragsprogramms vom Server-Computer das Übertragen einer Hypertext-Transfer-Protocol- (HTTP) GET-Anforderung an einen Web-Server aufweist.
Verfahren nach Anspruch 6, wobei das Ziehen eines Auftragsprogramms vom Server-Computer das Übertragen einer File-Transfer-Protocol- (FTP) GET-Anforderung an einen FTP-Server aufweist.
Verfahren nach Anspruch 1, wobei das komplexe Problem das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung aufweist, und wobei das Ziehen von Daten vom Server das Ziehen einer Darstellung eines einzelnen Moleküls oder von Darstellungen eines Teilsatzes von Molekülen von der Molekülsammlung aufweist.
Verfahren nach Anspruch 9, wobei das Berechnen von Eigenschaften von Molekülen in der Molekülsammlung den Schritt aufweist: Bestimmen, ob die Moleküle an ein vorgegebenes Protein andocken werden.
Verfahren nach Anspruch 9, wobei das Berechnen von Eigenschaften von Molekülen in der Molekülsammlung das Bestimmen dreidimensionaler Strukturen jedes Moleküls in der Molekülsammlung aufweist.
Thread-basiertes System zum Ausnutzen der freien Rechenleistung eines oder mehrerer Computer, die über ein Netzwerk verbunden sind, zum Lösen eines komplexen Problems, wobei das System aufweist: (a) einen Server mit durch einen Computer ausführbaren Befehlen zum Speichern von Daten und Auftragsbeschreibungen, die mit einem komplexen Problem in Beziehung stehen, und zum Bereitstellen der Daten und der Auftragsbeschreibungen für Clients in Antwort auf Anforderungen von den Clients; und (b) einen Client mit durch einen Computer ausführbaren Befehlen zum Starten eines Thread zum Ziehen einer Auftragsbescheibung vom Server, zum Ziehen von Daten vom Server und zum Ermöglichen, daß ein Betriebssystem einen Zeitplan zum Ausführen des Threads automatisch plant.
System nach Anspruch 12, wobei der Server einen Hypertext-Transfer-Protocol- (HTTP) Server aufweist
System nach Anspruch 12, wobei der Server einen File-Transfer-Protocol- (FTP) Server aufweist.
System nach Anspruch 12, wobei der Thread ein freier Thread ist.
System nach Anspruch 12, wobei das komplexe Problem das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung aufweist und der Client dazu geeignet ist, eine Darstellung eines einzelnen Moleküls oder eines Teilsatzes von Molekülen von der Molekülsammlung am Server zu ziehen.
System nach Anspruch 16, wobei das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung das Bestimmen dreidimensionaler Strukturen jedes Moleküls in der Molekülsammlung aufweist.
System nach Anspruch 16, wobei das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung den Schritt aufweist: Bestimmen, ob die Moleküle in der Molekülsammlung an ein vorgegebenes Protein andocken werden.
Computerprogrammprodukt mit auf einem Computer ausführbaren Befehlen, wobei das Computerprogrammprodukt ein computerlesbares Medium ist, zum Ausführen der Schritte. (a) Starten eines Threads auf einem Client-Computer zum Ziehen einer mit einem Teilbereich eines komplexen Problems in Beziehung stehenden Auftragsbeschreibung von einem Server; (b) Ermöglichen, daß ein Thread-Scheduler, der durch ein Betriebssystem bereitgestellt wird, das auf dem Client-Computer ausgeführt wird, den Zeitablauf für die Ausführung des Thread automatisch plant; und (c) Ziehen von Auftragsdaten vom Server und Lösen des durch die Auftragsbeschreibung spezifizierten Teilbereichs in Antwort auf vom Server empfangene Daten.
Computerprogrammprodukt nach Anspruch 19, wobei das Ziehen einer mit einem Teilbereich eines komplexen Problems in Beziehung stehenden Auftragsbeschreibung von einem Server das Übertragen einer Hypertext-Transfer-Protocol- (HTTP) GET-Anforderung an einen Web-Server aufweist.
Computerprogrammprodukt nach Anspruch 19, wobei das Ziehen einer mit einem Teilbereich eines komplexen Problems in Beziehung stehenden Auftragsbeschreibung von einem Server das Übertragen einer File-Transfer-Protocol- (FTP) GET-Anforderung an einen FTP-Server aufweist.
Computerprogrammprodukt nach Anspruch 19, wobei das Starten des Thread das Zuweisen einer Priorität zum Thread aufweist, die niedriger ist als eine Priorität eines Benutzer-Thread.
Computerprogrammprodukt nach Anspruch 22, wobei der Thread-Scheduler den Zeitablauf der Ausführung des Thread basierend auf der dem Thread zugewiesenen Priorität plant.
Computerprogrammprodukt nach Anspruch 19, wobei der Thread bestimmt, ob ein in der Auftragsbeschreibung spezifiziertes Auftragsprogramm auf dem Client-Computer resident ist, wobei der Thread, wenn festgestellt wird, daß das Auftragsprogramm nicht auf dem Client-Computer resident ist, das Auftragsprogramm vom Server-Computer zieht.
Computerprogrammprodukt nach Anspruch 24, wobei das Ziehen des Auftragsprogramms vom Server-Computer das Übertragen einer Hypertext-Transfer-Protocol- (HTTP) GET-Anforderung an einen Web-Server aufweist.
Computerprogrammprodukt nach Anspruch 24, wobei das Ziehen eines Auftragsprogramms vom Server das Übertragen einer File-Transfer-Protocol- (FTP) GET-Anforderung an einen FTP-Server aufweist.
Computerprogrammprodukt nach Anspruch 19, wobei das komplexe Problem das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung aufweist, und wobei das Ziehen von Daten vom Server das Ziehen einer Darstellung eines einzelnen Moleküls oder von Darstellungen eines Teilsatzes von Molekülen von der Molekülsammlung aufweist.
Computerprogrammprodukt nach Anspruch 27, wobei das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung das Bestimmen dreidimensionaler Strukturen jedes Moleküls in der Molekülsammlung aufweist.
Computerprogrammprodukt nach Anspruch 27, wobei das Berechnen von Eigenschaften von Molekülen in einer Molekülsammlung den Schritt aufweist: Bestimmen, ob die Moleküle an ein vorgegebenes Protein andocken werden.