Nowe technologie Edukacja Kontakt O nas Dodaj do ulubionych Ustaw tę stronę jako startową

Artykuły dotyczące systemu QNX i jego zastosowań

 

QNX znaczy POSIX.

Opracował: Wiesław Barcikowski

Wydział Cybernetyki
Wojskowa Akademia Techniczna

Jeszcze do niedawna w naszym kraju dobór odpowiedniego systemu operacyjnego do odpowiednich zastosowań oparty był na jego popularności i dostępności bogatej kolekcji programów użytkowych (czytaj: możliwości skopiowania od kolegi) . Takie "fanaberie", jak szczegółowa analiza wymagań przyszłego systemu użytkowego i możliwości ich spełnienia przez proponowany system operacyjny, często były całkowicie pomijane lub traktowane powierzchownie (przecież to jakoś musi działać!). Tu można również przytoczyć spostrzeżenie p. Jarosława Demineta, autora artykułu p.t. "Jaja" (PC Kurier, 15/93, 22.07.1993r.), że programista "często niestety ... dostaje albo bierze do ręki narzędzie, które ogólnie jest równie dobre jak kuchenka mikrofalowa, ale kompletnie nie nadaje się do rozwiązania zadanego problemu" (tak jak "kuchenka mikrofalowa po prostu nie nadaje się do gotowania jajek!"). I to niestety różniło nasz rynek komputerowy (cały czas, wraz z rynkiem owocowo-warzywnym, uważany za "normalny" ) od rynku zachodniego, na którym panuje swego rodzaju "pluralizm". Jest tam miejsce dla różnych systemów operacyjnych, w szczególności dla systemów ukierunkowanych na konkretną dziedzinę zastosowań, np. systemy czasu rzeczywistego (ang. Real-Time Systems), systemy bieżącego przetwarzania transakcji (ang. On-Line Transaction Processing), systemy przetwarzania rozproszonego (ang. Distributed Processing Systems), itp.

Wychodząc z analizy wymagań danej dziedziny zastosowań użytkownik szuka systemu operacyjnego, który najlepiej je spełni i wcale nie musi to być system z czołówki zestawienia podającego liczbę zainstalowanych kopii.

W naszym kraju takie zestawienie tym bardziej nie oddaje rzeczywistej wartości systemów, gdyż liczba zainstalowanych kopii znacznie różni się od liczby kopii oficjalnie zakupionych(!), a należy zauważyć, że systemy bardziej zaawansowane technologicznie i systemy specjalizowane w zasadzie nie były rozprowadzane nielegalnie. Na szczęście, okres ten już chyba się kończy i wreszcie zacznie funkcjonować normalny rynek użytkownika mającego przede wszystkim na uwadze konieczność spełnienia wymagań jego systemu użytkowego.

W takiej sytuacji na pewno powstanie zapotrzebowanie na systemy operacyjne takie jak system QNX, kanadyjskiej firmy Quantum Software Systems.

Tysiące użytkowników na całym świecie wybrało ten system i z powodzeniem wykorzystuje we wszystkich obszarach zastosowań a przede wszystkim tam, gdzie istotny jest czas, nieubłaganie płynący czas rzeczywisty. Dotyczy to zarówno takich "klasycznych" systemów czasu rzeczywistego, jak:

  • systemy sterowania i monitorowania (ang. SCADA - Supervisory Control And Data Acquisition), np. sterowanie procesem produkcji w fabryce,
  • systemy bezwzględnego funkcjonowania szczególnie uwarunkowane czasowo (ang. mission-critical systems), np. nadzorowanie pacjentów chorych na serce,
  • systemy bieżącego przetwarzania transakcji, np. obsługa transakcji dokonywanych za pomocą kart kredytowych, itp.

jak i mniej uwarunkowanych czasowo systemów administracyjnych, np. system kadrowo-płacowy przedsiębiorstwa (z podsystemem automatycznej rejestracji czasu pracy opartym np. o karty kodowe) czy systemy obsługi punktów sprzedaży (ang. POS - Point Of Sale) -przecież nikt nie lubi czekać na reakcję systemu po naciśnięciu klawisza (w szczególności, gdy przy okienku stoi zniecierpliwiony klient!).

W szczególności QNX jest nie do zastąpienia wszędzie tam, gdzie trzeba zintegrować wiele terytorialnie rozproszonych, niezależnych od siebie elementów w jeden spójny, poprawnie funkcjonujący system, gdy niezbędne jest rozproszenie obliczeń w celu zwiększenia niezawodności i wydajności całego systemu, czyli w rozproszonych systemach czasu rzeczywistego takich jak, np.:

  • rozproszone systemy sterowania i monitorowania,
  • rozproszone systemy komunikacyjne,
  • rozproszone, kompleksowe systemy zarządzania
  • rozproszone systemy przetwarzania transakcji (rozproszone bazy danych).

Takie aplikacje stawiają przed systemem operacyjnym najwyższe wymagania.

Odpowiedź na pytanie: co umożliwia systemowi QNX spełnienie tych wymagań przedstawione zostanie w dalszej części artykułu.

QNX jest obecny na rynku od ponad 10 lat - wprowadzony na rynek w 1982 roku, był w tamtym czasie pierwszym wielozadaniowym i wielodostępnym systemem operacyjnym dla mikrokomputera IBM PC, który właśnie pojawił się na rynku. Pierwowzorem systemu QNX był system operacyjny THOTH (nazwany imieniem egipskiego boga mądrości, nauki i magii) będący wynikiem prac badawczych dotyczących technik komunikacji międzyprocesorowej prowadzonych na Uniwersytecie Waterloo w Kanadzie. Dwóch pracowników uniwersytetu Dan Dodge i Gordon Bell, zainspirowanych systemem THOTH, zaprojektowało i zaimplementowało dla mikrokomputera IBM PC nowy system operacyjny, który został nazwany pierwotnie QUNIX (czy ktoś to jeszcze pamięta?). System został wprowadzony na rynek przez firmę Quantum Software Systems utworzoną przez autorów systemu. Nazwa "Qunix" nie spodobała się firmie AT&T, która uznała, że zbyt mocno przypomina ona nazwę "Unix" (która jest zastrzeżonym znakiem towarowym właśnie firmy AT&T). W odpowiedzi na ten zarzut firma Quantum usunęła z nazwy obie samogłoski i tak powstała nazwa QNX.

W kolejnych latach powstawały kolejne wersje zawierające ulepszenia dostosowujące system do dynamicznie rozwijającej się bazy sprzętowej oraz wymagań rynku (mikrokomputer IBM AT, procesory 32-bitowe, zintegrowana sieć lokalna, itd.). Zasadnicza zmiana nastąpiła w dziesięć lat po premierze. W 1991 roku firma Quantum wprowadziła na rynek nową wersję systemu - QNX v.4.0. Oprócz wielu udoskonaleń zwiększających wydajność, modularność i możliwości sieciowe, wprowadzono istotne novum: QNX v.4.0 jest całkowicie zgodny ze standardem POSIX (ang. Portable Operating System Interface for Computer Environment). Zdefiniowany przez IEEE (ang. Institute of Electrical and Electronic Engineers) POSIX określa sprzęg między systemem operacyjnym a światem zewnętrznym (aplikacje i użytkownicy). Aktualnie QNX spełnia opublikowane do tej pory zalecenia standardu POSIX:

  • 1003.1 - sprzęg systemowy,
  • 1003.2 - interpreter poleceń i narzędzia,
  • 1003.4 - czas rzeczywisty

Wiele przemawia za tym, że POSIX może stać się uniwersalną platformą dla Systemów Otwartych (ang. Open Systems). Np. coraz częściej różne instytucje (w tym agendy rządowe USA) wybierając system operacyjny do własnych zastosowań, stawiają warunek zgodności ze standardem POSIX. Zgodność ze standardem POSIX otwiera przed systemem QNX nowe możliwości:

  • znacznie zwiększa się ilość dostępnych aplikacji (zgodność na poziomie kodu źródłowego pozwala na ich bezproblemową implemetację)
  • zwiększa się ilość użytkowników mogących bez przygotowania wykorzystywać system (zgodność ze środowiskiem użytkownika systemu UNIX: shell, polecenia, biblioteki C, itp.)
  • zwiększa się "akceptowalność" systemu w różnych zastosowaniach i przez różnych (nawet tych sceptycznie nastawionych) użytkowników (zgodność z obecnym i przyszłym "standardem" systemu operacyjnego).

Czyli innymi słowy, na zewnątrz - QNX oferuje uniwersalne środowisko programistyczne systemu UNIX. Jeżeli zaś chodzi o strukturę wewnętrzną jest to zupełnie inny system operacyjny.

System QNX różni się od systemu UNIX dwoma elementami mającymi kardynalne znaczenie dla systemu operacyjnego: strukturą modułową i architekturą opartą o technikę przesyłania komunikatów (model client - server).

W przeciwieństwie do struktury systemu UNIX opartej o monolityczne jądro (rys.1), system QNX składa się z wielu współpracujacych ze sobą modułów zwanych procesami zarządzającymi (ang. managers ). Moduły te kooperują ze sobą za pośrednictwem niewielkiego jądra (ang. mikrokernel) systemu o wielkości zaledwie 8 kbajtów (rys.2). Dla porównania: jądro systemu UNIX zajmuje conajmniej 700 kbajtów.

Mikrojądro systemu QNX składa się z czterech części (rys.3):

  • IPC - obsługuje komunikację między procesami
  • network interface - zapewnia przezroczystą komunikację międzyprocesową w sieci lokalnej
  • hardware interrupt redirector - przechwytuje wszystkie przerwania i skierowuje je do odpowiednich procesów obsługujących
  • realtime scheduler -planuje przydział czasu procesora dla procesów zgodnie z zaleceniami standardu POSIX 1003.4.

Mikrojądro realizuje wywołania tylko 12 funkcji (ang. kernel calls).

Wszystkie pozostałe funkcje systemu operacyjnego (administrowanie procesami, gospodarka pamięcią operacyjną, zarządzanie zbiorami, urządzeniami wejścia/wyjścia, współpraca z siecią lokalną, operatorem, itp.) realizowane są właśnie przez procesy zarządzające..

Jądro traktuje procesy zarządzające w identyczny sposób jak "normalne" procesy użytkowe (np. proces kompilatora). Wszystkie procesy systemu (zarządzające i użytkowe) mogą być ładowane, uruchamiane, zawieszane i usuwane niezależnie od siebie i może być to wykonywane dynamicznie w czasie normalnej pracy systemu ("w biegu" - ang. on the fly). W zależności od wymagań zewnętrznych (chwilowych bądź stałych) można dany proces zarządzający zainstalować bądź usunąć (wyjątkiem jest Process Manager, który musi być zawsze zainstalowany). Pozwala to na elastyczne konfigurowanie systemu, np. po co w komputerze bezdyskowym Filesystem Manager?.

Procesy zarządzające różnią się od procesów użytkowych jedynie priorytetami (najwyższe w systemie) oraz poziomem uprzywilejowania do realizacji niektórych instrukcji mikroprocesora. System QNX wykorzystuje trzy poziomy uprzywilejowania obsługiwane przez procesor:

  • poziom 0 - mikrojądro,
  • poziom 1 - procesy zarządzające (Proc, Fsys, etc.)
  • poziom 3 - procesy użytkowe

(poziom 2 - aktualnie niewykorzystywany).

Na poziomie 3 niedostępne są instrukcje odwołujące się bezpośrednio do portów we/wy oraz podsystemu przerwań. Uprzywilejowany użytkownik ma możliwość tworzenia własnych procesów mających pełny dostęp do wszystkich elementów sprzętowych (opcja kompilatora: cc -T1). Pozwala to rozszerzać system o nowe moduły np. drivery niestandardowych urządzeń zewnętrznych. W ten elastyczny sposób można stopniowo "budować" docelowy system użytkowy (tak jak dzieci budują domek z klocków LEGO !), przy czym granica między modułami tworzącymi system operacyjny a modułami "czysto" użytkowymi jest bardzo płynna i nie ma znaczenia z punktu widzenia funkcjonowania systemu użytkowego.

Wszystkie procesy systemu QNX: zarządzające i użytkowe komunikują się ze sobą za pomocą techniki zwanej przesyłaniem komunikatów (ang. message passing). Za właściwe przesyłanie komunikatów między zadaniami odpowiedzialne jest mikrojądro, a właściwie jego moduł - IPC (ang. Inter-Process Communication).

W systemie QNX dostępne są trzy funkcje umożliwiające organizację komunikacji międzyprocesorowej: Send, Receive i Reply . Podstawowymi parametrami tych funkcji są: adres docelowy i treść komunikatu. Jeżeli adresatem jest proces uruchomiony w tym samym komputerze co proces-nadawca, komunikat jest przesyłany bezpośrednio. Jeżeli natomiast komunikat jest przeznaczony dla procesu wykonującego się w innym komputerze dołączonym do sieci QNX, IPC za pomocą modułu jądra Network Interface przesyła go do procesu odpowiadającego za współpracę z siecią -Network Manager. Proces ten za pomocą odpowiednich driver'ów sieci przesyła komunikat do właściwego komputera (węzła sieci). Technika ta pozwala na to, że procesy komunikują się ze sobą zawsze w taki sam sposób bez względu na ich umiejscowienie w sieci (proces nie musi używać specjalnych funkcji do komunikowania się za pośrednictwem sieci !).

Sieć QNX jest całkowicie przezroczysta, tzn. dowolny zasób sieci: dysk, drukarka, terminal, modem czy nawet procesor (zdalna realizacja procesów !) jest dostępny dla dowolnego procesu uruchomionego w dowolnym węźle sieci (!).

Wysoka efektywność komunikacji międzyprocesowej systemu QNX została osiągnięta dzięki przyjęciu tej techniki jako jednego z fundamentalnych założeń na etapie projektowania systemu oraz zaimplementowania jej w najniższej możliwej warstwie systemu operacyjnego (najbliżej sprzętu).

Właśnie umiejscowienie modułu IPC w strukturze warstwowej systemu (rys. 4) pozwala określić QNX jako rozproszony system operacyjny (ang. dist ributed operating system) w przeciwieństwie do sieciowych systemów operacyjnych (ang. networked operating system).

Dla porównania w sieciowym systemie operacyjnym moduł IPC jest umiejscowiony tuż poniżej warstwy Filesystem. Pozwala to wprawdzie zorganizować sieciowy system plików, ale wszystkie inne funkcje takie jak uzyskanie dostępu do zdalnego urządzenia zewnętrznego (np. modem) czy uruchomienie procesu w zdalnym węźle wymagają wykonania przez aplikację specjalnych czynności.

W systemie QNX naturalną możliwością jest zdalne uruchomienie procesu w dowolnym węźle sieci i co najważniejsze, proces ten może dziedziczyć środowisko procesu macierzystego (np. otwarte zbiory, urządzenia zewnętrzne. etc.), bo cała sieć jest po prostu przezroczysta !.

Dla przykładu, polecenie wydane w węźle nr 5 :

//1 //4/bin/sort <//2/user/baza.dan >//3/dev/par

spowoduje załadowanie z kartoteki /bin węzła nr 4 programu o nazwie sort i wykonanie go w węźle nr 1. Program ten będzie pobierał dane ze zbioru baza.dan z kartoteki /user z węzła nr 2 a wyniki drukował na drukarce podłączonej do węzła nr 3 (/dev/par).

Oczywiście, użytkownik musi mieć nadane odpowiednie uprawnienia pozwalające na realizację takiego przetwarzania.

Dzięki jednolitej dla sieci komunikacji międzyprocesowej oraz możliwości zarządzania nazwami globalnymi, znanymi w całej sieci (ang. network-wide name service) QNX tworzy środowisko, w którym aplikacje mogą wykorzystywać moc wszystkich procesorów dostępnych w sieci. Każdy użytkownik z kolei może traktować sieć QNX jako jednolity duży komputer składający się po prostu z procesów, zbiorów i urządzeń zewnętrznych i gdzie granice między fizycznymi węzłami są niewidoczne (rys. 5).

Implementacja przetwarzania rozproszonego stawia wysokie wymagania sieci lokalnej łączącej komputery. Struktura modułowa systemu QNX pozwoliła zaimplementować bardzo ciekawe i wysoce efektywne rozwiązanie sieci lokalnej nazwane FLEET.

Jak działa sieć QNX FLEET?

Do sieci mogą być podłączone dowolne mikrokomputery należące do rodziny IBM PC (poczynając od prostego XT). Każdy mikrokomputer może być wyposażony w kilka różnego typu adapterów sieciowych takich jak: Arcnet, Ethernet, Token Ring, które mogą pracować jednocześnie w tym samym czasie. Jednym słowem komputery mogą być połączone kilkoma różnymi sieciami jednocześnie !.

Projektanci sieci FLEET wykorzystali znane z zarządzania dyskami rozwiązanie, gdzie moduł zarządzający systemem zbiorów (Filesystem Manager ) współpracuje z różnymi typami pamięci zewnętrznych: dyski elastyczne, dyski twarde IDE, SCSI za pomocą odpowiednich programów obsługi (ang. driver).

Moduł zarządzania dostępem do sieci (Network Manager ) nie kontaktuje się bezpośrednio z adapterem sieciowym, lecz z jego driverem. Tak jak w przypadku pamięci zewnętrznych, można zainstalować wiele różnych lub takich samych adapterów sieciowych i sterujących nimi driverów (rys. 6). Zarówno Network Manager jak i drivery są niezależnymi modułami systemowymi i mogą być uruchamiane i zatrzymywane w dowolnym momencie podczas normalnego funkcjonowania systemu. Network Manager odpowiedzialny jest za przesyłanie komunikatów w sieci lokalnej. Drivery z kolei odpowiedzialne są za pakietowanie, kolejkowanie i ewentualną retransmisję danych. Tylko driver komunikuje się bezpośrednio z adapterem sieciowym.

Każdy węzeł sieci lokalnej identyfikowany jest dwoma numerami: logicznym i fizycznym. Numer logiczny jednoznacznie określa dany węzeł w całej sieci i jest używany przez współpracujące procesy do celów adresacji. Numer fizyczny węzła określony jest przez fizyczny numer adaptera sieciowego. Tak więc, pojedynczy węzeł (określany jednym numerem logicznym) wyposażony w kilka adapterów nosi kilka numerów fizycznych. Adaptery jednakowego typu umieszczone w różnych węzłach tworzą tzw. sieć logiczną. Węzły wyposażone w dwa lub więcej adapterów sieciowych połączone są dwoma lub więcej sieciami logicznymi (rys. 7). Za właściwe zarządzanie taką siecią (wybieranie sieci logicznej, przyporządkowywanie numerów logicznych i fizycznych) odpowiedzialny jest także Network Manager.

Co daje sieć QNX FLEET?

Wertując słownik angielsko-polski można znaleźć wiele znaczeń tego słowa m.in. rączy, chyży co oddaje jedną z podstawowych cech tej sieci, ale słowo to oznacza coś więcej:

  • Fault-Tolerant - odporność na awarie
  • Load-Balancing - wyrównywanie obciążenia
  • Efficient - efektywność, wydajność
  • Extensible - rozszerzalność
  • Transparent - przezroczystość.
  • Odporność na awarie.

Jeżeli węzły połączone są kilkoma sieciami logicznymi i jedna z sieci ulegnie awarii (uszkodzenie adaptera, przerwanie kabla) Network Manager automatycznie skierowuje dane inną siecią logiczną. Odbywa się to "w biegu", bez wiedzy i udziału komunikujących się ze sobą procesów. Pozwala to na tworzenie w pełni zdublowanych systemów (komputer, system dyskowy, osprzęt sieciowy) o wysokim stopniu niezawodności (co z tego, że mamy niezawodny system dyskowy z zaimplementowanym RAID5 skoro uszkodzenie kabla sieciowego może zatrzymać działanie systemu !!).

Wyrównywanie obciążenia.

Przepustowość sieci określona jest zarówno przez szybkość sprzętu sieciowego jak i szybkość komputera. Jeżeli komputer może dostarczać dane szybciej niż adapter sieciowy jest w stanie przesyłać to wówczas sieć staje się wąskim gardłem. Ale nie w przypadku sieci FLEET.

Jeżeli węzły połączone są kilkoma sieciami logicznymi i Network Manager stwierdzi, że osiągnięta została maksymalna przepustowość jednej sieci logicznej, automatycznie skierowuje dalsze dane kolejną siecią logiczną. Jednoczesna praca wielu sieci logicznych pozwala na zwielokrotnienie przepustowości - oglądanie na jednym komputerze obrazu z kamery video podłączonej do drugiego komputera przestało być problemem!.

Efektywność.

Drivery wykorzystują technikę podwójnego buforowania co pozwala osiągnąć prawie maksymalną wydajność (95% dla Arcnet, 80-95% dla Ethernet). W zależności od potrzeb, mogą być wykorzystywane albo gwarantujące wysoką przepustowość adaptery Ethernet (980 Kb/sek!) albo gwarantujące determinizm transmisji adaptery Arcnet czy Token Ring. Połączenie obydwu technik w jednym komputerze gwarantuje uzyskanie optymalnej efektywności.

Rozszerzalność.

W każdej chwili można dołożyć kolejny adapter tworząc nową sieć logiczną. Dla zupełnie nowych technologii sieciowych wystarczy stworzyć tylko odpowiednie drivery - reszta systemu pozostaje bez zmian !.

Przezroczystość.

Termin ten został już wyjaśniony poprzednio.

System QNX został ponadto zoptymalizowany pod kątem funkcjonowania w sieci bezdyskowych stacji roboczych:

  • możliwość ładowania systemu operacyjnego za pośrednictwem sieci,
  • możliwość włączenia do sieci komputerów pozbawionych monitora ekranowego i klawiatury ( np. typowe sterowniki przemysłowe lub węzły obliczeniowe - ang. compute server), oczywiście przy zachowaniu pełnych możliwości zdalnego sterowania,
  • Client-Side Cache znacznie przyspieszający wydajność stacji roboczej (coś w rodzaju ram-dysku, ale z automatycznym odświeżaniem zawartości - jest on całkowicie niewidoczny dla użytkownika).

Charakteryzując sieć należy wspomnieć również, że w systemie QNX został zaimplementowany protokół TCP/IP.

Firma Quantum skorzystała z gotowego rozwiązania Berkeley Software Distribution i po uzyskaniu odpowiedniej licencji zaimplementowała kod źródłowy BSD Network Software Net 2. Jako ciekawostkę należy podać, że implementacja nie wymagała zmiany ani jednej linii kodu źródłowego!. Dowodzi to dużej zgodności z systemem UNIX.

Zaimplementowany został pełny zestaw usług typu "klient", np. finger, ftp, rexec, rlogin czy telnet oraz odpowiadający mu zestaw typu "server", np. fingerd, ftpd, rexecd, rlogind czy telnetd. Ponadto w celu zapewnienia przenośności gotowych aplikacji unixowych zaimplementowana została również biblioteka funkcji Unix Socket's API (connect, gethost, inet, listen, recv, rxec, send, socket, etc.).

Aplikacje wykorzystujące TCP/IP kontaktują się z siecią za pośrednictwem modułu Network Manager tak samo jak "zwykłe" aplikacje systemu QNX. Pozwala to na wykorzystywanie tego samego drivera i adaptera sieciowego (nie trzeba wydzielać specjalnej sieci Ethernet dla potrzeb TCP/IP), czyli jednoczesne przesyłanie po tej samej sieci zarówno komunikatów QNX jak i TCP/IP.

Moduł zarządzający protokółem TCP/IP nazywa się Sockets Resource Manager i może być dynamicznie uruchamiany i zatrzymywany w trakcie normalnej pracy systemu. Może być również dostępny (tak jak wszystkie zasoby systemu) dla aplikacji uruchomionych w innych węzłach. Dzięki temu nie musimy instalować adaptera Ethernet w każdym komputerze. Np. jeżeli mamy sieć Token Ring to wystarczy aby tylko jeden jej węzeł wyposażyć dodatkowo w adapter sieci Ethernet - usługi TCP/IP staną się dostępne dla wszystkich pozostałych węzłów!.

Zaawansowane techniki sieciowe są jednym z warunków umożliwiających stosowanie systemu QNX w systemach użytkowych o najwyższych wymaganiach - rozproszonych systemach czasu rzeczywistego. Drugim warunkiem jest spełnienie ostrych wymagań jakie stawia praca w reżimie czasu rzeczywistego.

QNX jest systemem operacyjnym czasu rzeczywistego.

Dla wyjaśnienia terminu "czas rzeczywisty" przytoczona zostanie opinia J.Barlow'a, dyrektora firmy Concurrent Computer Corporation, produkującej wieloprocesorowy system operacyjny czasu rzeczywistego RTU: "system 'czasu rzeczywistego' nie tylko powinien zapewniać odpowiedź na zewnętrzne zdarzenia w z góry określonym czasie, ale także powinien przetwarzać dane otrzymywane ze świata zewnętrznego z ich szybkością napływania" ("Unix gets groomed for real_time duty", Computer Design, June 1,1990). Więcej informacji na temat problemów związanych z przetwarzaniem w czasie rzeczywistym oraz określenie wymagań jakie musi spełniać system operacyjny czasu rzeczywistego można znaleźć w artykule "UNIX w systemach czasu rzeczywistego?" zamieszczonym w poprzednim numerze Unix Forum (Nr 5(6), sierpień 1993).

Wymagania czasu rzeczywistego stawiane systemom operacyjnym zostały również uwzględnione w pracach standaryzacyjnych prowadzonych przez IEEE i zawarte w definicji POSIX 1003.4. Jak twierdzi Inder Singh z firmy Lynx Real-Time Systems "POSIX wymusza na producentach zdefiniowanie jednolitego sprzęgu na poziomie źródłowym, pozostawiając jednocześnie całkowitą swobodę co do wewnętrznej architektury jądra" ("Unix gets groomed...., jak poprzednio).

Właśnie odpowiednia architektura jądra uwzględniająca wymagania czasu rzeczywistego pozwala określić dany system operacyjny jako system czasu rzeczywistego.

W przeciwieństwie do systemu UNIX, system QNX został zaprojektowany jako system czasu rzeczywistego i spełnia wszystkie wymagania stawiane takim systemom (w tym w szczególności wymagania określone w definicji POSIX 1003.4.):

Zarządzanie procesami.

  • 255 współbieżnych procesów w jednym węźle,
  • 32 poziomy stałych priorytetów,
  • bezwzględne wywłaszczanie procesów o priorytecie niższym przez procesy o priorytecie wyższym (ang. fully preemptive sheduling),
  • metody szeregowania procesów na tym samym poziomie priorytetów:
    • * karuzelowa (ang.round-robin, time-slicing),
    • * FIFO (ang. First-In First-Out),
    • * adaptacyjna (ang. adaptive sheduling, dynamic priorites),
    • proces-serwer wykonuje się na poziomie priorytetu zlecającego procesu-klienta (ang. client-driven priorities),
    • funkcje tworzenia procesów:
    • * fork() - tworzy nowy proces na bazie kodu procesu wywołującego,
    • * exec() - zamienia wywołujący proces na proces wywoływany,
    • * spawn() - tworzy nowy proces będący potomkiem procesu wywołującego, bazujący na kodzie zawartym w innym zbiorze (nowy proces może być utworzony w dowolnym węźle sieci !),
    • stała dostępność procesów w pamięci operacyjnej (ang. no process swapping),
    • bardzo efektywne przełączanie procesów (ang. context-switch time):

* dla procesora 486/33MHz zmiana kontekstu zajmuje tylko 12 mikrosekund

* w nowej wersji QNX v.4.2 zoptymalizowanej dla procesora Pentium zmiana kontekstu ma zajmować ok. 1 mikrosekundy,

Komunikacja międzyprocesowa.

  • metody komunikacji i synchronizacji międzyprocesowej,
  • * przesyłanie komunikatów ( ang. message passing),
  • * procesy komunikacyjne (ang. proxies),
  • * wyjątki (ang. signals, exceptions),
  • bardzo efektywne przesyłanie komunikatów:
  • * przesłanie 1 bajtu między dwoma procesami uruchomionymi w procesorze 486/33MHz zajmuje tylko 30 mikrosekund,
  • * przesłanie 1 bajtu między dwoma procesami wykonującymi się w dwóch różnych węzłach zajmuje ok. 1 milisekundy,

Obsługa przerwań.

  • zagnieżdżanie przerwań,
  • w pełni wywłaszczalna obsługa (ang. fully preemptive interrupt system): przerwanie o wyższym priorytecie zawsze wywłaszcza przerwanie o niższym priorytecie - gwarantuje to determinizm odpowiedzi systemu (niemożliwe do określenia w systemie UNIX),
  • przerwania odbiera mikrojądro (moduł: Hardware Interrupt Redirector) i po odblokowaniu przerwań uruchamia odpowiednią procedurę obsługi (ang. interrupt handler), która może być napisana w języku C (być częścią procesu użytkowego!)
  • bardzo efektywna obsługa przerwań (rys.8): dla procesora 486/33MHz
  • * opóźnienie wejścia do obsługi przerwania (ang. interrupt latency) Til wynosi tylko 6 mikosekund,
  • * opóźnienie wznowienia przerwanego procesu Tiret wynosi 5 mikrosek.

Obsługa czasomierzy.

  • możliwość uruchomienia wielu czasomierzy (ang. timers) dla 1 procesu,
  • czasomierze mogą być: synchroniczne i asynchroniczne, jednokrotne i powtarzalne,
  • czasomierze mogą generować zdarzenia wyjątkowe (ang. events), inicjować sygnały lub uruchamiać procesy komunikacyjne (ang. proxies),
  • rozdzielczość czasomierzy: 1 nanosekunda (jeśli sprzęt dopuszcza).

Wymagania sprzętowe.

  • procesor: INTEL 8088, 80286, 80386, 80486, Pentium,
  • pamięć operacyjna:
  • * < 640K (runtime system),
  • * 2M (development system),
  • * zajętość pamięci przez niektóre moduły systemu:
  • Microkernel: 8K
  • Process Manager: 63K
  • Shared Library: 18K
  • Filesystem Manager 62K
  • Floppy driver 12K
  • Hard WD driver 8K
  • Hard SCSI driver 10K
  • Device Manager 25K
  • Console driver 20K
  • Serial driver 10K
  • Parallel driver 7K
  • Network Manager 20K
  • Arcnet driver 14K
  • Ethernet driver 20K
  • (z wyjątkiem Microkernel i Process Manager wszystkie moduły są opcjonalne i mogą być dynamicznie ładowane i usuwane z systemu)
  • możliwość wykorzystania przez procesy pamięci współdzielonej (ang. shared memory)
  • pamięć dyskowa:
    • * 0 (LAN workstation)
    • * 5M (OS + utilities)
    • * 4M (development system)
  • możliwość ładowania systemu QNX wraz z aplikacjami do pamięci ROM.

Przedstawione powyżej parametry techniczne dowodzą, że QNX jest bardzo efektywnym systemem operacyjnym i może być z powodzeniem stosowany w różnego rodzaju systemach czasu rzeczywistego poczynając od prostych sterowników przemysłowych a kończąc na rozproszonych systemach sterowania i zarządzania, czyli wszędzie tam gdzie jest wymagane bezwzględne reagowanie na zewnętrzne zdarzenia w skończonym i z góry określonym czasie.

Każdego użytkownika mikrokomputera IBM PC zainteresuje również na pewno integracja systemu QNX z systemem DOS. W systemie QNX można uruchomić specjalny program zarządzający DOS-Filesystem Manager, który udostępnia system zbiorów DOS. Za pomocą typowych poleceń systemu QNX można w 'przezroczysty' sposób korzystać ze zbiorów systemu DOS znajdujących się na dyskach twardych i elastycznych w dowolnym węźle sieci. Dostęp ten jest również możliwy dla aplikacji użytkowych systemu QNX.

Na specjalną uwagę zasługuje program Rundos umożliwiający uruchamianie programów użytkowych systemu DOS pod kontrolą systemu QNX. Rundos cechuje niespotykana innych emulatorach możliwość uruchamiania systemu MS Windows w tzw. trybie standardowym. Pozwala to programom o dużym zapotrzebowaniu na pamięć (np. Ventura Publisher) udostępnić pamięć rozszerzoną komputera, co jest warunkiem ich uruchomienia. Nie jest to możliwe w emulatorach bazujących na wirtualnym trybie pracy procesora 8086.

Pod kontrolą emulatora Rundos można bez problemów uruchomić najpopularniejsze i najczęściej używane programy zarówno systemu DOS (Brief, Crosstalk, Norton-Utilities, WordPerfect, itd.) jak i środowiska Windows (Corel Draw, MS Excel, Ms Word, Ventura Publisher, itd.). Programy użytkowe systemu DOS uruchamiane pod kontrolą emulatora Rundos zachowują się tak jak w środowisku macierzystym z tym, że realizują się szybciej (!). Jest to zasługą bardzo efektywnego systemu zbiorów QNX bazującego na znacznie lepszej i nowoczesnej architekturze wewnętrznej (dla przykładu: przekopiowanie 50 zbiorów o sumarycznej wielkości ok. 1Mb z dysku twardego na dyskietkę trwało w systemie DOS ok. 100 sek., podczas gdy ta sama operacja w systemie QNX wymagała zaledwie ok. 40 sek.!).

Rundos umożliwia ponadto programom DOS dostęp do wszystkich zasobów sieci QNX (dysków, drukarek, ploterów, modemów, itp.) podłączonych do dowolnych węzłów. W efekcie można uzyskać jakby sieciową wersję systemu DOS i to z, niespotykanym w innych systemach sieciowych, bezpośrednim dostępem do urządzeń podłączonych do portów szeregowych.

Aplikacje DOS mogą komunikować się z aplikacjami QNX za pośrednictwem zbiorów lub bezpośrednio (z pominięciem systemu zbiorów) za pomocą tzw. pseudo-terminali (emulowanych w pamięci operacyjnej). Rundos umożliwia przedefiniowanie portu COM systemu DOS i przywiązanie go do konkretnego pseudo-terminala.&127;Pozwala to na budowanie systemów użytkowych typu klient-serwer opartych o aplikacje systemów DOS i QNX.

System QNX z racji swych dużych walorów użytkowych jest często poddawany testom (w szczególności porównawczym) przez czasopisma informatyczne. Takie porównanie systemu QNX z systemem SCO UNIX zostało ostatnio zamieszczone w znanym czasopiśmie UNIX Review (Vol.11, No.3, 1993). W ramach działu "Off the shelf" opublikowany został artykuł Tima Parkera pt. "QNX 4.1". Tim Parker, szef firmy TPCI Test Labs z Kanady, jest stałym współpracownikiem UNIX Review i często jako niezależny ekspert dokonuje ocen popularnych produktów programowych.

W artykule, poza charakterystyką systemu QNX oraz oceną (wysoką) jego możliwości, autor zamieścił wyniki porównanania z systemem SCO Unix.

Badane były następujące parametry:

  • czas kompilacji programów w języku C (wielkość kodu: 125Kb i 2.4Mb),
  • czas wykonania programów (testy: sieve, Dhrystone i primes),
  • przesyłanie komunikatów,
  • wykonanie funkcji umask(),
  • zapis/odczyt zbioru (wielkość: 25MB),
  • przepustowość sieci Ethernet.

Z wyjątkiem testu dotyczącego funkcji umask() , gdzie SCO Unix okazał się prawie trzykrotnie szybszy (okrojone mikrojądro QNX nie było optymalizowane pod tym kątem), w pozostałych testach QNX zdecydowanie górował nad uznanym konkurentem. W przypadku operacji zapisu/odczytu zbioru QNX okazał się ponad 4 razy szybszy, a przesyłanie komunikatów zajmowało w systemie QNX czas nawet 10 razy krótszy niż w systemie SCO Unix (rys.9).

Takie wyniki testów pozwalają aby zamiast podsumowania zaprezentować opinię, Dawida White'a, autora artykułu "QNX, A Real Time MultiEverything OS that Runs On LANs" zamieszczonego w znanym czasopiśmie 'LAN Magazine' (January 1989): "gdyby firma IBM wybrała system QNX dla mikrokomputera IBM PC, wprowadzenie na rynek modelu AT mogłoby zostać opóźnione, gdyż aplikacje uruchamiane pod systemem QNX w komputerach PC zachowują się tak, jakby zostały uruchomione pod systemem DOS w komputerze AT z procesorem 386".

Oczywiście komentarz ten należy traktować z przymrużeniem oka, gdyż rozwój technologii mikroprocesorowej dokonuje się bez względu na aktualne możliwości oprogramowania, natomiast interesujące jest samo porównanie podkreślające możliwości systemu operacyjnego QNX.