Skip to end of banner
Go to start of banner

Multiple App/Device Operation [DE]

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »


Allgemein

Generell entsteht oft die Anforderung mehrere COMSOL-Geräte innerhalb einer Applikation oder mit mehreren Applikationen auf ein COMSOL-Gerät zuzugreifen. Dieses Dokument beschreibt die Möglichkeiten und was dabei beachtet werden sollte.


Multiple-Device:

Der Zugriff auf mehrere COMSOL-Geräte durch eine Applikation problemlos möglich. Erreicht wird dies durch einen wiederholten Aufruf der xChannelOpen-Funktion und der Parametrierung unterschiedlicher Board-Names. Der wiederholte Aufruf hat das Generieren eines weiteren Channel-Handles zur Folge dessen Handling im weiteren Verlauf der Applikation erforderlich ist. Durch die Auswahl des Handle, bei der Übergabe des hChannel-Parameters in eine der xChannel-Funktionen, wird bestimmt welches Gerät angesprochen wird.

Idealerweise sollte das Prozessdaten-Handling der beiden Geräte voneinander sowie das Handling vom Rest der Applikation voneinander entkoppelt sein (Multithreading, Multiprocessing). Dies ist auch bei einem Single-Device Betrieb empfohlen.

Multiple-Application

Ob ein Multi-Application Betrieb möglich ist, hängt wesentlich vom verwendeten Treiber ab. Grundsätzlich müssen mehrere Instanzen der Applikation bzw. des Treibers einander bekannt sein, dass Sperrmechanismen für die verwendeten Ressourcen greifen.

Unabhängig vom verwendeten Betriebssystem sollten folgenden Faktoren beachtet werden: Jeder Aufruf der xChannelIORead oder xChannelIOWrite zieht automatisch ein Handling der Handshake-Flags nach sich. Das Handshaking steuert den Zugriff auf das DPM und kann, abhängig vom eingesetzten Protokoll-Stack sowie vom eingestellten Betriebs-Modi, synchron zum Buszyklus sein. Ein erneuter Aufruf von xChannelIORead/Write wäre in diesem Fall ein "blockender" Aufruf. Erst mit dem nächsten Buszyklus und dem toggeln des Handshake wird die Funktion zurückkommen und einen Wert zurückliefern. Der Wert stammt in diesem Fall jedoch nicht mehr aus demselben Buszyklus.

Umgekehrt ist in einem asynchronen Betrieb völlig unklar, ob die Werte zweier Calls der xChannelIORead/Write-Funktionen aus unterschiedlichen oder demselben Buszyklus stammen.

Windows

Beim Windows-Treiber sind die wesentlichen Bestandteile des Treibers im Kernel-Space implementiert. Der Teil des Treibers der die relevanten Ressourcen schützt, wird also nicht in mehreren Prozessen gestartet. Dadurch ist ein Betrieb mehrerer Applikationen, die auf eine CifX-Karte zugreifen, also grundsätzlich möglich.

Linux

Im Standard Linux-Treiber ist der Signifikate Teil des Treibers als Userspace-Modul ausgelegt. Jeder Instanz des Treibers bzw. einer Applikation läuft in einem eigenen Prozess. Da keine Interprozesskommunikation im Treiber implementiert ist, sind die Ressourcen zwischen den jeweiligen Treiber-Instanzen ungeschützt. Von Haus aus ist also ein Betrieb mehrerer Applikationen nicht möglich.


  • No labels