Równoległe przetwarzanie

System Inferno jest systemem rozproszonym. Powoduje to, że programowanie równoległe jest zalecanie i potrafi przynieść dość duży wzrost wydajności. Dlatego też istotą VGCG jest możliwość wykonywania procesu odśmiecania na wielu wątkach. Każdy z trzech elementów garbage collectora typu mark & sweep (jakim jest VGCG) jest całkowicie niezależny od pozostałych i może działać w oddzielnym wątku bez potrzeby używania dodatkowych mechanizmów synchronizacji.

Niezależność poszczególnych operacji związanych z odśmiecaniem pozwala przenieść je na inny procesor dzięki czemu właściwe wykonywanie programu nie jest w żaden sposób dodatkowo spowalniane i działa tak samo wydajnie jak w sytuacji gdy garbage collector nie jest używany.

Mark & sweep

Najpopularniejszym rodzajem algorytmów odśmiecania pamięci jest mark & sweep. Polega on na zlokalizowaniu i oznaczeniu wszystkich używanych obszarów pamięci (czyli takich do których istnieją odwołania) a następnie zwolnieniu pozostałego miejsca. Zwykle garbage collector tego typu składa się z trzech elementów:

• mutator – właściwy kod programu, w nim znajduje się kod zajmujący się przydzielaniem pamięci na żądanie aplikacji
• marker – wyszukuje i oznacza nieużywane obiekty w pamięci
• sweeper – zwalnia obiekty które marker uznał za nieużywane

Epoki

Czas działania programu jest podzielony na epoki. Podczas każdej z nich w osobnych wątkach uruchomione zostają poszczególne elementy garbage collectora (muatator, marker i sweeper). Dodatkowo każdej epoce jest przyporządkowany jeden z trzech kolorów: COLOR(epoch) = epoch mod 3.

Przydzielanie pamięci

Pamięć jest przydzielana przy użyciu free lists. Jest to lista wskazujących na siebie wolnych bloków pamięci. Dzięki temu, że każdy wolny blok zawiera wskaźnik na następny, nie ma potrzeby tworzenia dodatkowych struktur danych do przechowywania tego typu informacji. Każdy przydzielany w ten sposób obiekt jest oznaczony kolorem aktualnie trwającej epoki.

Marker

W każdej epoce marker porusza się po wskazujących na siebie obiektach. Jeżeli kolor obiektu jest inny niż kolor aktualnej epoki marker uaktualnia go a następnie rekursywnie przegląda wszystkie bloki na które wskazuje dany obiekt. Gdy marker zakończy działanie wszystkie używane obiekty mają kolor danej epoki.

Warto zauważyć że mutator i marker w żaden sposób nie wpływają na swoje działanie. Mutator oznacza wszystkie nowe obiekty kolorem aktualnej epoki, a ten jest przez markera ignorowany. Istotny jest także fakt, że marker nigdy nie spotka bloku oznaczonego kolorem innym niż kolor aktualnej, bądź poprzedniej epoki.

Sweeper

Sweeper przegląda listę przydzielonych bloków w poszukiwaniu obiektów oznaczonych kolorem epoki COLOR(epoch-2). Jeśli natrafi na taki obszar pamięci to jest on zwalniany. Jest to operacja całkowicie bezpieczna ponieważ ani marker ani mutator nie mają dostępu do obiektów oznaczonych takim kolorem.

W przypadku natrafienia przez sweeper bloków o innym kolorze są one ignorowane, ponieważ wciąż mogą być w użyciu przez pozostałe elementy programu.

Zakończenie epoki

Gdy sweeper i marker zakończą pracę program przechodzi do kolejnej epoki o nowym kolorze i cały proces zaczyna się od nowa. Dzięki całkowitej niezależności poszczególnych elementów od siebie mutator, marker i sweeper mogą działać równolegle bez potrzeby wprowadzania blokad, co korzystnie wpływa na wydajność systemu.

Podsumowanie

Obecnie bardzo wiele języków programowania oferuje wbudowany garbage collector dlatego rozwój algorytmów tego typu nie jest niczym dziwnym. Dlatego taż warto dowiedzieć się na jakiego rodzaju rozwiązania można w tej dziedzinie natrafić.

Jest to główną przyczyną powstawania systemów eksperymentalnych. Brak zgodności ze standardami czy brak nacisku na niektóre aspekty (najczęściej jest to wydajność) powodują, że z reguły nie nadają się one do użytku codziennego, czy to jako serwer czy jako desktop. W żaden sposób nie zmniejsza to jednak wartości takich projektów. Są nimi, między innymi rozwijane przez Bell Labs systemy Plan 9 oraz Inferno, które w założeniu mają być następcami Uniksa.

Zasoby i pliki

W systemach Inferno i Plan 9 każdy zasób jest reprezentowany przez plik. Przypomina to założenia projektowe Uniksa ale jest na to kładziony jeszcze większy nacisk. Każde urządzenie, proces, sieć, połączenie sieciowe czy nawet otwarte okno jest osobnym plikiem. Dodatkowo zawartość tych plików może być generowana dynamicznie w zależności od stanu zasobu lub konkretnego klienta.

Wyspecjalizowane sterowniki najczęściej są reprezentowane przez katalog zawierający pliki data i ctl. Pierwszy z nich służy do operacji wejścia-wyjścia, podczas gdy drugi jest używany do konfiguracji i kontroli urządzenia. Innym ciekawym przykładem jest nawiązywanie połączeń TCP, które odbywa się poprzez serię zapisów do odpowiednich plików reprezentujących konkretny sterownik.

Także, wszelkie usługi i serwery są reprezentowane jako pliki. Jeżeli program w celu nawiązania połączenia internetowego potrzebuje adresu IP serwera obsługującego daną domenę otwiera plik reprezentujący usługę DNS i za jego pomocą uzyskuje odpowiednie informacje. Najczęściej dzieje się to poprzez wpisanie do pliku nazwy domeny, a następnie odczytanie adresu IP. To rozwiązanie jest szczególnie wygodne, zwracając uwagę na fakt, że zarówno lokalne i jak i zdalne zasoby są w ten sposób reprezentowane. Wspomniany serwer DNS wcale nie musi działać na tym samym komputerze.

Prawa dostępu do plików pozwalają jednocześnie dokładnie określić prawa dostępu do poszczególnych usług, zasobów i urządzeń. Natomiast przechowywanie wszystkich obiektów (także np. połączeń sieciowych czy procesów) w postaci plików upraszcza wewnętrzną budowę systemu. Jedyny sztywno zapisany interfejs dotyczy samej obsługi systemu plików podczas gdy cała reszta jest oparta na plikach.

Styx

Traktowanie każdego zasobu czy usługi jako osobnego pliku wymaga odpowiedniego protokołu usprawniającego komunikację w systemach rozproszonych. Jego zadanie jest zbliżone do NFS, lecz można wskazać pewne wyraźne różnice. Przede wszystkim NFS jest przystosowany głównie do obsługi zwykłych plików, a nie np. generowanych w procfs. Styx jest przystosowany do obsługi każdego rodzaju plików.

Każde odwołanie się klienta do systemu plików jest tłumaczone na szereg komunikatów protokołu Styx. Dla zapewnienia bezpieczeństwa wspierana jest autoryzacja klientów przy pomocy certyfikatów, a także szyfrowanie transmisji. Jest to mechanizm całkowicie niewidoczny dla aplikacji korzystających z protokołu Styx.

Limbo

Programy dla systemów Plan 9 oraz Inferno są pisane w specjalnie do tego zaprojektowanym języku programowania Limbo. Jest on kompilowany do kodu pośredniego wykonywanego następnie przez maszynę wirtualną Dis. Limbo jest także językiem bezpiecznym oferującym silną kontrolę zgodności typów.

Limbo oferuje także kanały jako mechanizm komunikacji między procesami. Każdy kanał ma ściśle określony typ. Wymiana danych jest synchronizowana: proces, który chce wysłać lub odebrać dane musi czekać na gotowość drugiego procesu. Możliwe jest także utworzenie buforowanych kanałów które nie wymagają blokowania procesów z nich korzystających.

Programy są zbudowane z modułów. Każdy moduł oferuje określony publiczny interfejs. Możliwe jest załadowanie wielokrotnie tego samego modułu z różnymi implementacjami. Kod jest wykonywany przez procesy, które przypominają swoim wyglądem i zachowaniem wątki w innych systemach operacyjnych.

Dis

Do uruchamiania programów napisanych w języku Limbo Inferno używa maszyny wirtualnej Dis. Podczas gdy większość języków programowania tego typu, domyślnie używa stosowych maszyn wirtualnych, Dis jest maszyną rejestrową. Twórcy tłumaczą to nieznacznie wyższą wydajnością oraz łatwością przystosowania maszyny do działania na innej platformie sprzętowej. Uważają, także że maszyna wirtualna powinna jak najbardziej przypominać architektury na których pracuje.

Kod może być przez Dis kompilowany just-in-time lub interpretowany przez odpowiednią bibliotekę. Niezależnie od tego jest on umieszczony w osobnym obszarze pamięci do którego nie można uzyskać dostępu żadną z instrukcji oferowanych przez Dis.

Dane są podzielone na globalne, wspólne dla całego kodu zawartego w danym module oraz lokalne dla danej funkcji, umieszczone na stosie. Dostęp do nich uzyskuje się korzystając z adresów bazowych zawartych odpowiednio w rejestrach mp (module pointer) i fp (frame pointer). Można także podawać bezpośrednie adresy w przestrzeni danych programu, nie korzystając z tych rejestrów.

Dis oferuje zestaw instrukcji podobny do procesorów CISC. Różni się on głównie o wiele wyższym poziomem abstrakcji. Oprócz podstawowych instrukcji takich jak jmp czy mov oferowany jest także zestaw instrukcji wspomagający operacje na tablicach, alokację pamięci, czy ładowanie modułów.

Format plików

Dis obsługuje własny format plików wykonywalnych, stworzony specjalnie po to aby dostosować się do jego szczególnych właściwości. Każdy taki plik wykonywany przez maszynę wirtualną składa się z sześciu części:

• nagłówek – zawiera sygnaturę pozwalającą rozpoznać format pliku, a także sprawdzić czy jest podpisany (i ewentualnie zawiera także podpis). Z tej sekcji Dis odczytuje wszystkie wymagania programu odnośnie środowiska w jakim będzie uruchomiony. Możliwe opcje to np. wymuszenie kompilacji JIT lub interpretacji kodu. Inne informacje przechowywane w nagłówku to rozmiary pozostałych sekcji oraz punkt wejścia programu.
• kod – jest to sekcja zawierająca ciąg instrukcji maszyny wirtualnej. Każda instrukcja składa się z opcode, sposobu adresowania i trzech argumentów.
• sekcja typów – umieszczone są w niej deskryptory umożliwiające lokalizację wszelkich wskaźników i referencji w każdym obiekcie. Każdy deskryptor zawiera mapę bitową w której każdy bit reprezentuje jedno słowo. Jeżeli bit jest ustawiony oznacza to, że dane słowo jest wskaźnikiem na inny obiekt.
• dane – ta sekcja zawiera dane dostępne później przy użyciu rejestru mp. Każdy wpis w tej sekcji opisuje rodzaj danych, ich położenie, typ i ewentualnie ilość obiektów.
• nazwa modułu
• sekcja linków – jest to sekcja używana do dynamicznej konsolidacji modułów. Zawiera informacje o wszystkich eksportowanych funkcjach: nazwę, wskaźnik oraz informację o typie argumentów.

Odśmiecanie

Przechowywane informacje o typach pozwalają na realizację systemu odśmiecania pamięci. W celu polepszenia wydajności składa się on z dwóch mechanizmów. Pierwszy z nich to zwykłe zliczanie referencji – proste i stosunkowo szybkie. Nie nadaje się jednak do usuwania obiektów wzajemnie do siebie odwołujących się. Z tego powodu jest także stosowany algorytm Very Concurrent Garbage Collection (VCGC). Pozwala on na zrównoleglenie procesu odśmiecania i tym samym wykorzystania faktu, że Inferno jest systemem rozproszonym. Dzięki temu, że odśmiecanie nie przerywa działania głównego programu możliwe jest zbudowanie systemu czasu rzeczywistego. Sam algorytm VCGC jest tematem na osobny artykuł. Dis umożliwia wykorzystywanie zliczania referencji, VCGC lub hybrydy obu tych rozwiązań.

Podsumowanie

Inferno i Plan 9 mają za zadanie rozwinąć technologie mogące zastąpić Uniksa. Pod pewnymi względami kontynuują przyjęte w nim założenia (“wszystko jest plikiem”), lecz z drugiej strony maszyna wirtualna jest odmienną technologią wykorzystywaną w wielu nowoczesnych językach programowania. Są to systemy niewątpliwie bardzo ciekawe i warto im się bliżej przyjrzeć.

Podstawowe założenia

Programowanie zorientowane aspektowo w żadnej swojej formie nie wyklucza programowania obiektowego. Właściwie to jest jego uzupełnieniem dostarczającym dodatkowe elementy pozwalające inaczej spojrzeć na projekt aplikacji. Aspektowe języki programowania pozwalają na wskazanie miejsc w kodzie obiektowym w których mają zostać wykonane dodatkowe operacje. Istnieje wiele implementacji tego, lecz zdecydowanie najbardziej popularny jest AspectJ stworzony dla Javy. Wprowadza on następujące elementy:

• pointcut – ogólny opis miejsca przecięcia kodu w którym mają zostać wykonane operacje definiowane przez aspekt. W większości sytuacji jest to wywołanie lub wykonanie kodu funkcji składowej, ale możliwe jest także zdefiniowanie pointcuta przy każdej operacji wykonanej przez metody w danej klasie. Pointcuty mogą także dotyczyć każdego dostępu do pola lub tworzeniu obiektu.
• joinpoint – konkretne miejsce przecięcia kodu w którym zostaną wstawione dodatkowe operacje definiowane przez dany aspekt.
• advice – definiuję operację jaka ma zostać wykonana w joinpointach. Kod opisany w advices jest najczęściej wstawiany przed lub po wywołaniu metody w klasie, ale także w przypadku rzucenia wyjątku lub oryginalna funkcja składowa zostaje całkowicie przez niego zastąpiona.

W przypadku AspectJ a także wielu innych języków aspekt jest traktowany jak klasa. Oprócz wyżej opisanych elementów może zawierać funkcje składowe lub pola. Mogą być tworzone ich instancje, ale najczęściej aspekt jest singletonem. Dodatkowo można utworzyć hierarchię aspektów korzystając z dziedziczenia. Wiele implementacji pozwala także na istnienie abstrakcyjnych aspektów oraz wirtualnych pointcutów.

Realizacja

W przypadku Javy i AspectJ aspekty są realizowane w czasie kompilacji z niewielkim wsparciem refleksyjności dzięki czemu nie wpływają w dużym stopniu na wydajność. W przypadku AspectC++ w związku brakiem wsparcia dynamicznego metaprogramowania ze strony C++ kod aspektowy (napisany w AspectC++) jest najpierw tłumaczony do kodu obiektowego (C++) i dopiero wtedy kompilowany. Bibliotek wprowadzająca aspekty w C# LOOM.NET wykonuje wszystkie operacje z tym związane podczas działania programu, podobnie rzecz się ma w przypadku modułu Perla Aspect. Generalnie sposób realizacji jest inny dla różnych bibliotek i także powinien być świadomym wyborem ponieważ, może w dość dużym stopniu wpłynąć na wydajność programu.

Zastosowanie

Najbardziej oczywistymi zastosowaniami programowania aspektowego to wszelkiej maści loggery i narzędzia diagnostyczne. Można także użyć ich do kontrolowania zgodności otrzymanych danych z kontraktami, ale należy pamiętać, że wiele zalet aspektów jest zauważalna dopiero wtedy gdy odnoszą się do tych samych operacji wykonywanych w wielu metodach. Przykładem może być realizacja wzorca Obserwator, gdzie każda zmiana stanu obiektu obserwowanego wymaga poinformowania o niej obiekty obserwujące. W tym przypadku najlepszym rozwiązaniem jest wstawienie po wywołaniu każdej metody (nie oznaczonej jako const) klasy obiektu obserwowanego wywołania metody uaktualniającej obiekty obserwujące.

Przykład

Warto przedstawić prosty przykład użycia aspektów w realizacji wzorca Obserwator. Zwykłe podejście wymagałoby czegoś podobnego do kodu poniżej:

class Obserwowany {
	// ...
	public void metoda1(int wartość) {
		// ... operacje ...

		uaktualnijObserwatorów();
	}

	public void metoda2(string tekst) {
		// ... operacje ...

		uaktualnijObserwatorów();
	}
}

W przypadku AspectJ kod realizujący te same funkcje mógłby wyglądać następująco:

class Obserwowany {
	// ...
	public void metoda1(int wartość) {
		// ... operacje ...
	}

	public void metoda2(string tekst) {
		// ... operacje ...
	}
}

aspect WzorzecObserwator {
	pointcut operacja() : execution(public * Obserwowany.*(..));
	after() : operacja() {
		uaktualnijObserwatorów();
	}
}

Ten przykład bardzo dobrze prezentuje główne założenie aspektów. Jest nim pozbycie się często powtarzanego kodu niezwiązanego z głównym przeznaczeniem metody z jej kodu. Taka izolacja ma na celu sprawienie kodu bardziej przejrzystym i ułatwienie wprowadzenia ewentualnych zmian.

Problemy

Głównym problemem związanym z programowaniem aspektowym jest fakt, że sam pomysł jest stosunkowo młody i w związku z tym wsparcie jest wciąż niewielkie. O ile ze znalezieniem odpowiednich narzędzi nie powinno być problemów to kwestia przyzwyczajenia programistów i to, że języki modelowania takie jak UML nie zostały stworzone z myślą o aspektach sprawiają, że wciąż nie zyskało dużej popularności.

Podsumowanie

Programowanie aspektowe, mimo że z niskopoziomowego punktu widzenia nie zmienia praktycznie niczego, to bez wątpienia jest w stanie wprowadzić pewne uporządkowanie w miejscu gdzie typowe programowanie obiektowe pozostawiło dużą swobodę. Rozwiązanie ciekawe, ale jest tylko jednym z wielu sposobów na ominięcie pewnych problemów co sprawia, że nie odnosi, jak na razie, spektakularnych sukcesów.

Ogólna budowa

Choices jest napisanym w C++ systemem operacyjnym zorientowanym obiektowo. Jako całość jest tworzony z wielu odrębnych obiektów współpracujących ze sobą. Składa się z frameworków definiujących poszczególne aspekty jego działalności. Dziedziczenie jest wykorzystywane do łatwego przenoszenia systemu na inne platformy i do stosowania zależnych od sprzętu optymalizacji. Choices wspiera SPARC, x86 oraz ARM, a także istnieje możliwość jego uruchomienia w trybie użytkownika na Solarisie i Linuksie.

Wyjątki procesora

Chocies korzysta z dobrodziejstw języków programowania wysokiego poziomu także w przypadku wyjątków procesora. Każde przerwanie jest obsługiwane przez InterruptManagera. Przekazuje on stosowne informacje do odpowiednich elementów systemu operacyjnego, lub jeżeli przerwanie jest wyjątkiem procesora zgłasza błąd. InterruptManager rzuca wtedy wyjątek C++ (model jego obsługi nie ma znaczenia), w taki sposób, aby stos wskazywał, że został on rzucony z miejsca w którym wystąpił wyjątek procesora. Dzięki temu kod obsługi wyjątków może zlokalizować błędną operację i wykonać odpowiednie czynności.

Odzyskiwanie po awarii

Choices wspiera mechanizmy odzyskiwania stanu programu (bądź jądra) w przypadku ewentualnych błędów spowodowanych wadliwym kodem lub nieprawidłowym funkcjonowaniem sprzętu.

• przeładowanie kodu – jest to mechanizm uaktywniający się, gdy procesor zasygnalizuje próbę wykonania nieprawidłowej operacji, które są najczęściej oznaką błędu sprzętowego związanego z pamięcią operacyjną. W tej sytuacji wadliwa instrukcja jest ponownie ładowana z innego źródła danych (np. obrazu jądra trzymanego w pamięci flash). Dodatkowo, możliwe są okresowe kontrole poprawności kodu opierające się na zgodności sum kontrolnych. Ten mechanizm może być zastosowany jedynie do kodu, który nie jest generowany run-time.
• mikrorestart jest wykonywany najczęściej gdy błąd wystąpi podczas wykonywania funkcji dostarczanej przez komponent. Polega na ponownym załadowaniu, przygotowaniu do działania i kolejnej próbie wywołania funkcji. W odróżnieniu od poprzedniego mechanizmu, mikrorestart skupia się głównie na próbie odzyskania uszkodzonych struktur danych, gdzie pomocne są także opisane w dalszej części artykułu Server State Regions.
• automatyczny restart usługi – dotyczy głównie serwerów działających jako procesy w trybie użytkownika. Polega właściwie na tym samym co mikrorestart, z tym, że także próbuje radzić sobie z ewentualnymi problemami wynikającymi z utrzymywanych przez proces blokad oraz dostępu do pamięci współdzielonej. W celu umożliwienia skutecznego restartu usługi, Choices monitoruje wszystkie blokady utrzymywane przez procesy. W sytuacji gdy proces ulegnie awarii, blokady są zwalniane, tak aby nie powodowały problemów po wznowieniu działania programu.

• transakcje – jest to sposób radzenia sobie z ewentualnymi błędami szeroko wykorzystywany w bazach danych. Transakcje polegają na zachowaniu kopii danych, tak aby można było całkowicie anulować wykonywaną operację, jeżeli którykolwiek z jej elementów się nie powiedzie. Innymi słowy, w przypadku napotkania błędu, dane pozostają niezmienione. Dzięki temu ewentualne błędy, nie mogą naruszyć integralności danych.

Kontrolowane restarty

Innym istotnym mechanizmem, co prawda jeszcze niezaimplementowanym, są policy-driven restarts. Dają programistom możliwość dokładnego opisania sposobu ponownego uruchamiania programu, tak aby dostosować go do konkretnych potrzeb. Możliwe jest także zdefiniowanie pewnych operacji jako reakcję na określony błąd zastępującą zwykły restart programu.

Server State Regions

Część mikrojąder jest zaprojektowana w taki sposób, że każdy serwer przetrzymuje wszystkie potrzebne mu dane na temat każdego z klientów. Jest to rozwiązanie proste i wygodne zarówno dla jądra jak i poszczególnych serwerów działających w przestrzeni użytkownika. Sprawia to jednak, że działanie programu jest uzależnione od przypisanych mu danych obecnych w usługach z których korzysta. W rezultacie, mimo izolacji poszczególnych komponentów, błąd w kodzie serwera wciąż może doprowadzić do błędu aplikacji z niego korzystających.

Rozwiązanie tego problemu, jakie zastosowano w Choices polega na przeniesieniu wszystkich danych aplikacji poza przestrzeń adresową serwera. Tworzy się w ten sposób tak zwane Server State Regions, obszary pamięci przechowujące wymagane przez konkretną usługę dane na temat aplikacji. SSR pomimo że są tworzone z pamięci dostępnej klientom, są dla nich ze względów bezpieczeństwa niedostępne. Dzięki temu, serwer może bezpiecznie umieścić w nich wszystkie informacje jakie dotyczą konkretnych aplikacji.

Gdy aplikacja po raz pierwszy skorzysta z usług oferowanych przez dany serwer, zostanie utworzony dla niej osobny SSR. Następnie przy każdym wywołaniu funkcji serwera odpowiedni SSR jest tymczasowo mapowany do jego przestrzeni adresowej¹. Po wykonaniu wszystkich potrzebnych operacji i powrocie do kodu aplikacji serwer ponownie traci dostęp do SSR.

W przypadku awarii serwera zostaje on automatycznie uruchomiony ponownie. Dzięki SSR błąd serwera może naruszyć poprawność danych co najwyżej jednej aplikacji, podczas gdy wszystkie pozostałe nie odczują żadnych skutków awarii. Dodatkowo po restarcie serwer może uzyskać informacje na temat swojego poprzedniego stanu i spróbować naprawić ewentualne błędy w przetwarzanym SSR.

Zastosowanie SSR ma także szereg dodatkowych zaleta. Wykorzystywanie pamięci aplikacji do tworzenia SSR znacząco ogranicza możliwe sposoby przeprowadzenia ataku DoS na serwer. SSR są także niezależne od klienta, dzięki czemu mogą zostać wykorzystane do odzyskania dawnego stanu aplikacji przed jej ewentualną awarią. Oczywiście wymaga to dodatkowego wsparcia ze strony klienta i nie jest wspierane przez jądro w takim stopniu jak odzyskiwanie serwera, ale pozwala np. na niezerwanie połączeń TCP w przypadku błędu klienta.

¹ Warto zaznaczyć, że nie wpływa to w znaczący sposób na wydajność, ponieważ każde wywołanie funkcji udostępnianych przez serwer i tak powoduje unieważnienie TLB.

Podsumowanie

Choices nie jest projektem przeznaczonym do użytku. Należy na niego patrzeć jak na system edukacyjny i eksperymentalny, który łączy w sobie wiele różnych mechanizmów zapewniających większą niezawodność. Wiele z tych rozwiązań zostało już zastosowanych w innych mikrojądrach, ale w Choices stara się stworzyć z nich spójny system współpracujących ze sobą elementów. Projekt niestety zdaje się być obecnie martwy, ostatnie aktualizacje jego strony miały miejsce latem 2007 r. Innym problemem jest fakt, że wiele mechanizmów zostało szczegółowo opisanych, ale nie są jeszcze zaimplementowane.

C# i Sing#

Projekt jest w przeważającej większości napisany w C#. Według danych Microsoftu 95% kodu mikrojądra jest napisana w tym języku. Pozostałe to assembler x86 oraz C++ wykorzystane przy niskopoziomowej obsłudze pewnych podstawowych elementów systemu, o czym później. W tym miejscu nie można nie wspomnieć o Sing#. Jest to zestaw rozszerzeń do C# wspierający wiele dodatkowych mechanizmów często wykorzystywanych w kodzie Singularity. Dodatkowe elementy zawarte w Sing# to między innymi:

• kontrakty – pozwalają na zachowanie bezpieczeństwa typologicznego podczas komunikacji międzyprocesowej realizowanej przez kanały (channels). Kontrakty definiują jakie wiadomości mogą być przesyłane, typy oraz wymagania co do wartości ich argumentów oraz kierunek w jakim są wysyłane. Kontrakty pozwalają także na ustalenie oczekiwanych komunikatów na każdym etapie transmisji.
• endpoints – każdy kontrakt definiuje endpointy przeznaczone dla obu stron komunikacji. Zawierają one wszystkie metody opisane w kontrakcie jako możliwe wiadomości i służa do wygodnego ich odbierania i wysyłania.
• exchange heap – Sing# pozwala na alokację obiektów w specjalnym miejscu przestrzeni adresowej zwanym stertą wymiany (exchange heap), która jest wykorzystywana przez wszelkie rodzaje komunikacji międzyprocesowej. Dodatkowo wykonywane są wszystkie informacje związane z zachowaniem informacji o właścicielu danego obiektu.
• konstrukcja switch-receive – razem z endpointami pozwala na wygodne odbieranie wiadomości opierając się na standardowej konstrukcji switch.

switch receive {
	case endpoint.Message1() :
		...
		break;
	case endpoint.Message2() :
		...
		break;
}

Bezpieczeństwo

C# (a także wszystkie rozszerzenia związane z Sing#) jest językiem bezpiecznym pod wieloma względami, na czym bazują główne założenia systemu Singularity. Można rozróżnić dwa obszary w których ograniczona została możliwość występowania błędów:

• bezpieczeństwo typów zapewnia, że wszystkie operacje wykonywane na obiekcie są zgodne z jego typem
• bezpieczeństwo pamięci zapewnia, że wszystkie odwołania do pamięci są poprawne. Wiąże się to z zerowymi wskaźnikami, odwołaniom poza rozmiar tablicy lub do nieistniejących obiektów.

Bartok

Programy pisane w C# lub innych językach związanych z platformą .NET zwykle są tłumaczone do pośredniego (także bezpiecznego) języka MSIL. Zadaniem kompilatora Bartok, będącego jedną z najważniejszych części Singularity jest tłumaczenie MSIL do kodu natywnego, zachowując przy tym bezpieczeństwo kodu. Odpowiednie optymalizacje pozwalają na stworzenie jak najbardziej wydajnego kodu wykorzystującego wszystkie możliwości danego komputera, co chociaż w pewnym stopniu jest w stanie zrekompensować straty wydajności spowodowane procedurami wsparcia runtime.

Jednolite procesy

Zapewnienie pełnego bezpieczeństwa kodu natywnego wymaga od Singularity wprowadzenie jeszcze dodatkowych ograniczeń w stosunku do procesów (a także i jądra):

• Kod programu nie może zostać zmodyfikowany w trakcie jego działania.

  Wyklucza to kompilację just-in-time (obecną np. na platformie .NET), a wszystkie dynamicznie konsolidowane biblioteki muszą zostać załadowane przed rozpoczęciem pracy programu.

• Żaden obiekt nie może należeć do więcej niż jednego procesu w tym samym czasie.

  To ograniczenie ułatwia synchronizację między procesami upraszczając sposób komunikacji między nimi.

Wymaga to między innymi udziału systemu operacyjnego w większości operacji mogących stanowić zagrożenie i tym samym wymusza użycie mechanizmów typu wspomniane wcześniej kontrakty. Istotne jest, że jądro także podlega tym ograniczeniom.

Dzięki tym ograniczeniom możliwe jest także zastosowanie refleksyjności czasu kompilacji (Compile Time Reflection). Żaden element kodu nie może zostać zmieniony w trakcie działania programu, dlatego też refleksyjność realizowana podczas kompilacji (czyli de facto w ostatnim momencie w którym kod może się zmienić) jest w zupełności wystarczająca.

Ochrona pamięci

Najczęstszym obecnie stosowanym mechanizmem mającym za zadanie ochronę przestrzeni adresowej poszczególnych procesów jest stronicowanie. Jako element realizowany sprzętowo HIP wiąże się z pewnymi spadkami wydajności, szczególnie w przypadku komunikacji międzyprocesowej, która wymaga operacjach na katalogu/tablicy stron skutkujących unieważnieniem TLB. Także wywłaszczenie procesu w większości sytuacji unieważnia przynajmniej część wpisów w TLB. Przez bardzo długi czas była to jedna z ważniejszych przyczyn małej popularności mikrojąder.

Każdy program (a także i kernel) w Singularity jest napisany w bezpiecznym języku programowania. Nie może on samodzielnie utworzyć lub unieważnić referencji do obiektów w pamięci a także wykonać żadnych innych operacji, które mogłyby zagrozić bezpieczeństwu systemu. Jedynie alokacja pamięci oraz garbage collector nie spełniają tej zasady, ale są to mechanizmy dostarczane przez system operacyjny i tym samym w pełni zaufane.

Skoro sam język programowania ogranicza programistę do podobnego stopnia jak HIP, sprzętowa ochrona pamięci staje się niepotrzebna. Jej rolę pełnią wszystkie funkcje kontrolne wsparcia runtime, które tym samym tworzą SIP. Wiąże się z tym także założenie, że każdy obiekt może należeć tylko do jednej przestrzeni adresowej. Z tego powodu pamięć współdzielona, a także wszelkie inne sposoby komunikacji międzyprocesowej inne niż kanały (channels) są niedozwolone.

Komunikacja międzyprocesowa

Komunikacja międzyprocesowa w Singularity opiera się na kanałach (channels). Wykorzystują one dodatkowe elementy Sing# opisane wcześniej: kontrakty i endpointy. Dzięki nim utrzymane jest bezpieczeństwo operacji związanych w komunikacją. Cała komunikacja odbywa się przy pomocy endpointów które dostarczają odpowiedni interfejs dla obu uczestników transmisji.

Dane przekazywane są przy użyciu sterty wymiany (exchange heap). W tym miejscu nie funkcjonuje garbage collector, zamiast niego wykorzystywane są liczniki referencji. Jest to obszar pamięci do którego ma dostęp każdy proces, ale zgodnie z zasadami dotyczącymi bezpieczeństwa każdy obiekt przez cały czas ma przyporządkowanego mu właściciela. Przekazanie obiektu odbywa się przez dostarczenie endpointowi odbiorcy wskaźnika na przesyłany obiekt (wewnątrz sterty wymiany).

Sterta wymiany ma też ograniczenia co do obiektów znajdujących się w niej. Przede wszystkim muszą być one wymiennego typu czyli nie mogą zawierać żadnych referencji do innych, nieprzesyłanych obiektów.

Podsumowanie

Singularity jest bez wątpienia bardzo ciekawym, ale też i bardzo rozbudowanym projektem. Ten artykuł opisuje jedynie najbardziej istotne cechy tego systemu, sprawiające, że wyróżnia się on na tle obecnie często stosowanych systemów. Jest to projekt eksperymentalny w którym nie wszystkie rzeczy są jeszcze w pełni ukończone, ale mimo to już zawiera wiele interesujących rozwiązań.

Najprawdopodobniej, w najbliższym czasie pojawi się kolejny artykuł opisujący mniej popularne ale wciąż bardzo istotne elementy systemu Singularity. Być może także pokuszę się o dokładniejsze opisanie któregoś z mechanizmów, bo projekty eksperymentalne zawsze warte są szczególnej uwagi.

Klasy

W języku Objective-C każda klasa jest także obiektem zawierające podstawowe informacje wymagane przez pozostałe funkcje wsparcia runtime. Najważniejsze z danych przechowywanych przez obiekty opisujące klasy to:

• nazwa klasy
• rozmiar instancji klasy (z uwzględnieniem klas bazowych)
• lista zmiennych składowych klasy
• lista funkcji składowych klasy
• wskaźnik na klasę bazową
• lista klas pochodnych
• realizowane protokoły

Traktowanie klasy jako obiektu (inspirowane Smalltalkiem) pozwala znacząco poszerzyć możliwości języka szczególnie jeżeli chodzi o refleksyjność. Struktury opisujące klasy najczęściej są przechowywane w wewnętrznych danych runtime. Odpowiednie informacje są wydobywane przy okazji tworzenia instancji danej klasy, a następnie wiązane nowym obiektem. Dlatego też poniższy kod:

array = [NSArray new]

zostanie w większości implementacji, już przez kompilator zamieniony na konstrukcję podobną do tej:

array = [(objc_get_class("NSArray")) new]

Funkcja objc_get_class przegląda listę wszystkich klas w poszukiwaniu żądanej i w przypadku jej odnalezienia zwraca wskaźnik do niej. Cała operacja ma miejsce już podczas działania programu, dlatego też istotna jest szybkość działania takich podstawowych operacji. Jednym ze sposobów na przyśpieszenie kodu jest cachowanie wskaźników na obiekty opisujące klasy. W rezultacie funkcja objc_get_class jest wykonywana jeden raz dla każdej klasy, a w każdym kolejnym przypadku używany jest zwrócony przez nią wskaźnik.

Obiekty

Wszystkie klasy w Objective-C dziedziczą po NSObject. Jest to klasa która realizuje większość operacji pozwalających na korzystanie przez programistę z informacji jakie są przechowywane o każdej klasie. Oferowana funkcjonalność to między innymi:

• sprawdzenie czy klasa odpowiada na selektor
• sprawdzenie czy klasa realizuje protokół
• podanie funkcji odpowiadającej na selektor
• wykonanie podanego selektora
• podanie nazwy klasy

Selektory

Selektory identyfikują wysyłaną do obiektu wiadomość, czyli innymi słowy, nazywają funkcję składową która powinna zostać wywołana. W większości jest to po prostu ciąg znaków odpowiadających nazwie funkcji, chociaż w niektórych implementacjach zawiera także unikalny numer identyfikacyjny. W celu usprawnienia operacji tłumaczenia ciągu znaków na selektor i odwrotnie istnieją odpowiednie tablice przechowujące listy wszystkich zarejestrowanych danych. Jako że mimo tego, może to być kosztowna operacja, umożliwiane jest (wręcz zalecane) tłumaczenie nazw do selektorów podczas kompilacji.

Wywołanie funkcji składowych

Wywołanie funkcji składowych, a właściwie zgodnie z nomenklaturą Objective C: wysyłanie wiadomości obiektom jest przeprowadzany w całkowicie dynamiczny sposób. Warto także zaznaczyć, że ponieważ klasy także są traktowane jako obiekty, statyczne funkcje składowe wywoływane są w taki sam sposób. Oto przykładowy kod wysyłania komunikatu do obiektu:

[obiekt metoda]

zostaje zamieniony na:

objc_msgSend(obiekt, @selector(metoda))

Funkcja objc_msgSend, na podstawie informacji zawartych w opisie klasy której instancją jest object, wywołuje odpowiednią metodę. Każda klasa zawiera listę selektorów oraz przypisanych im adresów funkcji. Procedura przekazująca wiadomość przeszukuje tę listę (z uwzględnieniem klas bazowych) w poszukiwaniu adresu odpowiedniej metody, która następnie zostaje wywołana.

Często, w celu przyśpieszenia tej bardzo częstej operacji, wykorzystywane są tak zwane dispatch tables. Właściwie pod każdym względem przypominają one tablice funkcji wirtualnych wykorzystywane np. w C++. Każda taka tablica zawiera jedynie adresy kolejnych funkcji składowych klasy. W tej implementacji unikalny numer identyfikacyjny selektora służy także jako indeks wskazujący na odpowiedni adres w tej tablicy. Najważniejszą różnicą między dispatch table a tablicami funkcji wirtualnych jest fakt, że dispatch tables najczęściej są tworzone już podczas działania programu na podstawie listy funkcji składowych zawartej w obiekcie opisującym klasę.

Pozostałe dane dotyczące klasy

Często zdarza się, że wpisy z adresami funkcji składowych i odpowiadającymi im selektorami zawierają także informację o przyjmowanych przez metodę argumentach. Jest to przydatne przy debuggingu. Podobnie rzecz się ma z wpisami dotyczącymi zmiennych składowych. Obiekt opisujący klasę przechowuję listę struktur zawierających nazwę każdej takiej zmiennej, jej typ (dla ułatwienie debuggingu) i przesunięcie w stosunku do bazowego adresu instancji.

Podsumowanie

Objective-C prezentuje inne podejście co do sposobu implementacji rozszerzeń związanych z OOP w C niż C++. Opiera się bardziej na wykonywaniu operacji podczas działania programu, co zmniejsza jego wydajność, ale z drugiej strony oferuje szereg dodatkowych możliwości. Niech za przykład posłużą tutaj choćby systemy rozproszone. W Objective-C przy odrobinie wysiłku ze strony osoby implementującej taki system, można tworzyć obiekty rozproszone w banalnie prosty sposób. Możliwe jest to właśnie dzięki dużej ilości informacji które zostają w kodzie po kompilacji, oraz wielu możliwościach wstawienia dodatkowego kodu podczas działania programu. Oczywiście takie rozwiązania są też możliwe w C++ czy innych językach, ale nie zawsze jest to aż takie proste.

Główną wadą Objective-C jest jego niewielka popularność. Przed śmiercią chroni go właściwie jedynie OpenStep. Warto jednak zwrócić uwagę na jego możliwości, ponieważ jest on gdzieś pomiędzy innymi językami kompilowanymi do kodu natywnego a kompilowanymi do kodu pośredniego. Z jednej strony wsparcie runtime jest bardzo rozbudowane, ale wciąż istnieje możliwość uzyskania maksymalnej możliwej wydajności w krytycznych miejscach, przez ograniczenie używania niektórych z jego funkcji.

Zainteresowani mogą ściągnąć Quarna tutaj lub bezpośrednio tutaj. Możliwe jest także ściągnięcie gotowego obrazu dyskietki w tym miejscu. Uprzedzam, że w wielu częściach kod jest jeszcze niedopracowany i czasami wręcz razi błędami, jednak głównym celem tego wydania było ustabilizowanie pewnej podstawy na bazie której będą prowadzone dalsze prace. W najbliższej przyszłości planuję po kolei zająć się poszczególnymi elementami systemu znacząco je dopracowując. Obecnie, są one jedynie zalążkami, których głównym zadaniem jest wykorzystanie możliwości podsystemu Manes.

Quarn w wersji 0.0.90 posiada zaimplementowane między innymi:

• Managed Execution System
• Execution Flow Controller
• podstawowe sterowniki (klawiatura, dma, fdc, pic, pit, rs232, pci)
• wielozadaniowość z planistą round-robin (wywłaszczanie)
• alokator pamięci O(1)
• podstawowe elementy interfejsu Hydra
• port Hydry do POSIX
• podstawowe wsparcie dla FAT12
• wsparcie dla RTTI w C++
• wsparcie dla plików ELF, dynamiczny konsolidator
• ładowanie modułów kernela
• wykonywanie zewnętrznych plików
• systemu zasobów, urządzeń i usług

W tym momencie należą się pewne wyjaśnienia co do niektórych elementów Quarna. Co prawda w przyszłości zamierzam napisać o nich dużo więcej, jednak teraz przynajmniej podam ogólny zarys ich działania.

Manes

Managed Execution System (Manes) jest systemem rozproszonej dystrybucji obiektów i komponentów (przypomina systemy typu CORBA czy COM). Jest sercem Quarna, rozwiązującym wszelkie kwestie związane z modułowością i komunikacją pomiędzy poszczególnymi elementami systemu. W przyszłośći Manes wspierać będzie także szereg dodatkowych technologii jak na przykład programowanie aspektowe.

Kolejnym elementem bardzo mocno związanym z Manes jest Execution Flow Controller. Wykorzystuje on tablice metod wirtualnych do wstrzykiwania kodu, który zostanie wykonany przed wywołaniem takiej funkcji składowej. Pozwala to na implementację większości funkcji dostarczanych przez Manes.

Hydra

Innym istotnym elementem Quarna jest Hydra czyli główne API jakie jest dostarczane aplikacjom. Obejmuje między innymi interfejs użytkownika (obecnie tylko w trybie tekstowym, w przyszłości także i w graficznym), operacje wejścia-wyjścia, wielowątkowość itp. Możliwe jest uruchomienie programów napisanych przy wykorzystaniu Hydry na każdym systemie zgodnym z POSIX dzięki specjalnej warstwie pośredniczącej. W Quarnie 0.0.90 jest to zaprezentowane za pomocą domyślnego shella.

Podsumowanie

Quarn jest projektem amatorskim w związku z czym prace nad nim czasowo ulegają większemu spowolnieniu. Nie skupiam się w nim na uzyskiwaniu jak największej funkcjonalności lecz na zastosowaniu ciekawych, nowych rozwiązań. Dlatego też obecna wersja nie powala swoimi możliwościami i służy głównie ułatwieniu w utrzymaniu porządku w kodzie.

Uzasadnienie

Praktycznie w każdej grze występuje główna baza obiektów w niej występujących. Zwykle są to instancje klas ściśle ze sobą powiązanych odpowiednią hierarchią. Wspólna funkcjonalność, zgodnie z duchem OOP, jest w miarę możliwości przenoszona do klas znajdujących się wyżej w hierarchii. Wszelkie odstępstwa od domyślnego zachowania są implementowane przy użyciu polimorfizmu.

Wraz ze wzrostem stopnia skomplikowania projektu coraz trudniej jest unikać dziedziczenia wielobazowego i wszystkich związanych z nim niedogodności, w trakcie pozbywania się duplikowanego kodu. Innym problemem który się pojawia jest powstanie bardzo dużych klas bazowych, które są zwykle wysoce niezalecane. Dochodzi do sytuacji gdzie programowanie zorientowane obiektowo najwyraźniej nie jest najlepszy sposobem na rozwiązanie danego problemu.

Podstawowe założenia

W powyższych sytuacjach bardziej istotnym od zarządzania obiektami jest wygodne zarządzanie logiką kodu. Realizowane jest to za pomocą dwóch podstawowych elementów programowania opartego na komponentach:

• jednostka (entity) – identyfikuje to co w OOP zostałoby nazwane obiektem. Nie posiada pól ani metod, jest jedynie czymś w rodzaju nazwy. Swoim przeznaczeniem przypomina klasę, ponieważ definiuje konkretne zachowanie, lecz ilościowo odpowiada obiektom.
• komponent (component) – definiują logikę operacji. Każdy komponent opisuje inne fragmenty zachowania jednostki. Najważniejszą różnicą między klasami a komponentami jest to, że klasy opisują pełną funkcjonalność, podczas gdy pojedynczy komponent tylko jej część. W większości implementacji komponenty są obiektami globalnymi realizowanymi przy pomocy wzorca singleton, jednakże nie jest to sztywną regułą.

Niezwykle istotnym elementem całego systemu jednostek jest przyporządkowywanie im konkretnych komponentów. Może to odbywać się na dwa sposoby, zależnie od implementacji. Także umieszczenie kodu i danych jest sprawą zależną od samej implementacji. Warto jednak pamiętać, że podstawowym założeniem programowania opartego na komponentach jest utrzymanie minimalnego rozmiaru jednostki. W rezultacie jest to najczęściej liczba całkowita.

Dane

W systemach opartych na tym paradygmacie dane są umieszczane w komponentach. W zależności od możliwych zastosowań jednostki, komponenty przechowują dane potrzebne do realizowania przez nie odpowiednich funkcji. Wymaga to dodatkowego mechanizmu komunikowania się pomiędzy komponentami różnych typów w sytuacji gdy potrzebna jest modyfikacja danych innego komponentu. Powinno to być jednak unikane. Główną zaletą jest uproszczenie mechanizmów związanych z synchronizacją w przypadku systemów wielowątkowych. Każdy komponent zajmuje się tylko swoimi danymi dzięki czemu można ograniczyć ilość blokad.

Dodatkowo najczęściej to komponenty przechowują informację o przyporządkowanym im jednostką. Dzięki temu zlokalizowanie wszystkich jednostek jest proste i nie wymaga istnienia dodatkowych struktur danych. W tej kwestii wiele jednak zależy od implementacji, bo nie da się ukryć, że zdarza się także sytuacja w której każda jednostka przechowuje listę przypisanych komponentów.

Kod

W przypadku kodu najpopularniejszym rozwiązaniem jest umieszczenie go także w komponentach. Wtedy co prawda jest on powiązany z danymi, co może przypominać OOP, jednak uzyskuje się duże rozdrobnienie funkcjonalności co ułatwia wiele kwestii. Oprócz wspomnianego ominięcia problemu synchronizacji, możliwa jest dynamiczna zmiana właściwości i metod obiektu (reprezentowanego przez jednostkę) co pozwala na ograniczenie ilości zajmowanej pamięci. Istotny jest także inny sposób zapisu kodu co jest główną cechą odróżniającą od siebie paradygmaty programowania. Znacząco ułatwia to dodanie dodatkowej funkcjonalności poprzez wprowadzenie kolejnego komponentu.

Komponenty ułatwiają także masowe wykonywanie operacji. Jeżeli dana funkcja powinna być wykonana na wszystkich obiektach danego typu, komponent potrafi to zrobić korzystając z posiadanej listy przyporządkowanych mu jednostek. Kluczowe jest tutaj ustalenie odpowiedniej kolejności wykonywania komponentów w odpowiedzi na zdarzenia.

Przykład realizacji

Przykładowe zastosowanie komponentów w grze polega na stworzeniu wystarczającej ich ilości do pokrycia każdego możliwego zachowania obiektów. Oczywiście, z reguły nie stosuje się tutaj żadnej hierarchii komponentów, ponieważ zwykle nie przynosi to żadnych korzyści. Każdy obiekt obecny w grze jest zarejestrowany w komponencie Render który udostępnia procedury związane z jego wyświetlaniem. Oprócz tego łódki mogą być zarejestrowane w komponencie Boat. Po ich zniszczeniu zostają usunięte z komponentu Boat a zarejestrowane w Wreck.

Główna pętla programu w odpowiedniej kolejności, często w odpowiedzi na konkretne zdarzenia wykonuje żądane komponenty. Dla przykładu, jeżeli samochód jest sterowany przez gracza, to należy do komponentu PlayerControl, którego procedury są wywoływane w odpowiedzi na zdarzenia z urządzeń zewnętrznych.

Podsumowanie

Programowanie oparte na komponentach zwane także bardziej szczegółowo Entity System jest bez wątpienia bardzo ciekawym spojrzeniem na sposób rozwiązania problemów związanych z dużą ilością podobnych obiektów, których implementacja zawiera jednak pewne różnice. Pozwalają one w takiej sytuacji na uporządkowanie kodu i co za tym idzie ułatwienia jego dalszej rozbudowy.

Jest to technika stosowana najczęściej w przypadku produkcji gier komputerowych co nie oznacza, że w innych dziedzinach nie może znaleźć ona zastosowania. Istnieje wiele różnych podejść do takich kwestii jak umieszczenie kodu czy sposób kojarzenia komponentów z jednostkami. Dzieje się tak, ponieważ nie ma tutaj uniwersalnego rozwiązania i każdy dostosowuje to do swoich potrzeb. Podobnie rzecz się ma gdy porównać komponenty do OOP. Trudno powiedzieć żeby jeden paradygmat był lepszy od drugiego. Ich zastosowanie jest odmienne i należy tak je używać, aby wykorzystać jak najwięcej ich zalet.

Podstawowe założenia

SOAP zakłada, że każda wiadomość jest wysyłana od konkretnego nadawcy do przynajmniej jednego odbiorcy przy opcjonalnym udziale jednego lub więcej pośredników. Każdy z elementów uczestniczących w przekazaniu wiadomości (tj. nadawca, pośrednik i odbiorca) jest nazywany węzłem i posiada swój własny adres URI. Dodatkowo, każda przesyłana wiadomość jest całkowicie niezależna od pozostałych, a protokół nie wspiera żadnych mechanizmów synchronizacji.

Budowa wiadomości

Każda wiadomość składa się z nagłówka (header) i ciała (body). Pierwszy z tych elementów może być analizowany przez każdego z pośredników, a także przez ostatecznych odbiorców. Ciało wiadomości jest zarezerwowane jedynie dla odbiorców. Poniżej przedstawiono strukturę wiadomości:

<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
        xmlns:m="http://www.example.org/timeouts"
        xmlns:xml="http://www.w3.org/XML/1998/namespace">
        <env:Header>
                ...
        </env:Header>
        <env:Body>
                ...
                <env:Fault>
                        ...
                </env:Fault>
        </env:Body>
</env:Envelope>

Nagłówek jest podzielony na bloki. Każdy blok posiada informację o roli do której jest przeznaczony, informacje czy musi być analizowany przez węzeł, informacje dotyczące warunków w których ma on być przekazany dalej oraz właściwe dane. Nagłówki służą głownie do realizacji przez pośredników dodatkowych zadań takich jak autoryzacja, logowanie czy dodatkowe mechanizmy bezpieczeństwa. Nagłówki są opcjonalne.

Ciało wiadomości jest częścią wymaganą przez standard, mimo że jej zawartość jest praktycznie dowolna. To właśnie w tym miejscu umieszczana jest treść wiadomości. Jedyną istotną rzeczą jest env:Fault jest to opcjonalny element używany do przekazywania informacji o błędach.

Cechy (features)

Niezwykle istotnym elementem protokołu SOAP są cechy (features), opisują one w dokładny sposób niemalże każdy aspekt całego procesu zdalnego wywołania procedury. Implementacje mają tutaj dość dużą dowolność, dzięki czemu mogą nadać pożądane w danym przypadku dodatkowe właściwości, które pozwolą lepiej wykorzystać możliwości protokołu SOAP.

Role (roles)

Role opisują zachowanie węzła po otrzymaniu danej wiadomości. Każdy blok w nagłówku posiada informację do jakiej roli jest przeznaczony, co decyduje czy węzeł powinien analizować zawartość danego bloku. Podobnie jak węzły i cechy, role także posiadają swój adres URI, który służy do ich identyfikacji. Wersja 1.2 standardu SOAP definiuje trzy role, lecz możliwe jest wprowadzenie dodatkowych.

• next – każdy pośrednik oraz odbiorca musi przeanalizować nagłówek wiadomości
• none – nagłówek wiadomości nie może być analizowany
• ultimateReceiver – nagłówek wiadomości jest analizowany jedynie przez ostatecznych odbiorców, jest to domyślna rola

Właściwości (properties)

Kolejnym istotnym elementem protokołu SOAP są właściwości. Przechowują one istotne informacje dotyczące wiadomości nie będące jednak jej częścią. Najczęściej dotyczą one szczegółów związanych z transmisją danych. Podobnie jak większość innych elementów SOAP właściwości także identyfikowane są adresami URI.

Istnieją dwa konteksty właściwości: kontekst węzła (environment context) i kontekst wiadomości (message exchange context). Pierwszy zawiera informacje dotyczące konkretnego węzła, takie jak jego numer IP czy lokalną datę i czas. Drugi oprócz standardowego opisu wiadomości takiego jak jej ID zawieta także informacje zależne od konkretnego MEP-a.

Wzorce wymiany wiadomości (MEP)

MEP jest wzorcem według którego węzły SOAP wymieniają miedzy sobą informację. Każdy wzorzec tego typu posiada swój własny adres URI. Ich implementacja jest ściśle zależna od rodzaju wykorzystywanego protokołu niższej warstwy. Dodatkowo w zależności od schematu wg którego przesyłane są dane transmisja jest podzielona na poszczególne etapy. Dwa schematy wymienione w standardzie (które muszą być implementowane przez obsługę HTTP) to Response Message Exchange Pattern i Request-Response Message Exchange Pattern. Zasadnicza różnica między nimi jest taka, że pierwszy schemat nie zakłada przesyłania szczegółowego żądania. Ogranicza się ono do prostego wywołania zależnego od używanego protokołu niższej warstwy (np. HTTP). W obu przypadkach odpowiedź jest pełnowartościową wiadomością SOAP.

Przetwarzanie wiadomości

Po otrzymaniu wiadomości każdy węzeł analizuje ją w poszukiwaniu informacji, które są dla niego przeznaczone. Wygląda to w następujący sposób.

1. Nagłówek wiadomości jest przeszukiwany pod kątem istnienia bloków przeznaczonych do roli jaką spełnia węzeł.
2. Odnajdywane są bloki nagłówka obowiązkowe do przetworzenia.
3. Jeżeli węzeł nie jest w stanie przetworzyć któregokolwiek z bloków znalezionych w powyższych punktach wysyłana jest zwrotna informacja o błędzie.
4. W przeciwnym wypadku węzeł przetwarza w odpowiedni dla siebie sposób znalezione bloki. Jeżeli jest jednocześnie ostatecznym odbiorcą przetwarza także ciało wiadomości.
5. W sytuacji gdy węzeł nie jest odbiorcą oraz nie wystąpił żaden błąd wiadomość jest przekazywana dalej z pominięciem przetworzonych bloków w nagłówku.

Transmisja wiadomości

W większości przypadków SOAP wykorzystuje do przesyłania danych protokół HTTP. Dzięki temu łatwiej jest zbudować system oparty na SOAP w sieci z firewallami i serwerami proxy. Warto także zauważyć, że HTTP idealnie odpowiada specyfice SOAP. Każda wiadomość SOAP, podobnie jak każde żądanie HTTP, jest całkowicie niezależna od pozostałych. Naturalnie, możliwe jest także wykorzystywanie HTTPS do transmisji wymagających większego bezpieczeństwa. Inną alternatywą, choć dość rzadko spotykaną i omawianą, jest wykorzystanie protokołu SMTP. Spotyka się także implementacje które dla zwiększenia wydajności operują bezpośrednio na niższej warstwie – protokole TCP.

Jak zostało to wspomniane w paragrafie o wzorcach wymiany wiadomości, transmisja jest podzielona na stany. Oto przykładowy przebieg transmisji Request-Response Message Exchange Pattern z użyciem protokołu HTTP.

• initOdpowiednia właściwość kontekstu wiadomości zawiera adres HTTP węzła do którego należy się połączyć. Wykorzystywana jest w zależności od konfiguracji i/lub implementacji metoda GET lub POST. W żądaniu HTTP umieszczone zostają wszystkie informacje dotyczące kodowania znaków. W tym czasie nasłuchujący adresat przyjmuje połączenie i jeżeli nie wystąpi żaden błąd oczekuje na zakończenie transmisji ze strony nadawcy.
• requestingUżywając metody określonej w poprzednim etapie przesyłana jest treść żądania do adresata. W zależności od odpowiedzi algorytm może powrócić do stanu init aby ponowić próbę (ma to miejsce np. przy przekierowaniach), fail jeżeli wystąpił bład lub sending+receiving jeżeli wszystko przebiegło pomyślnie. W tym samym czasie adresat jest w stanie responding w którym oczekuje na dane od nadawcy i po ich odebraniu wysyła odpowiedź.
• sending+receivingW tym stanie adresat przetwarza otrzymaną wiadomość. Transmisja danych jest zakończona.
• success lub failW zależności od wyniku przeprowadzonej operacji węzeł kończy przesyłanie danych z informacją o sukcesie lub porażce.

Serializacja danych

Niezbędnym elementem w każdym systemie zdalnych wywołań procedur jest mechanizm serializacji przekazywanych danych, takich jak argumenty funkcji. Nazwy występujące w programie wykorzystującym SOAP są modyfikowane w taki sposób aby mogły zostać użyte w każdym elemencie języka XML. Dlatego niedozwolone znaki zastępuje się ich wartością szestnastkową w UTF-16 (lub UTF-8) dla przykładu Hello world zostanie zamienione na Hello_x0020_world.

Wywołanie jest przedstawiane w ciele wiadomości jako element o nazwie takiej jak nazwa funkcji (oczywiście po zakodowaniu znaków niedozwolonych w XML-u) zawierający wszystkie wejściowe i wejściowo-wyjściowe argumenty. Każdy argument jest przedstawiany jako element o tej samej nazwie zawierający jego wartość (także po przekształceniu w formę akceptowalną dla XML-a). Odpowiedzią jest element o dowolnej nazwie zawierający wszystkie argumenty wyjściowe oraz wejściowo-wyjściowe. Sposób ich zapisu jest taki sam jak w przypadku wywołania. Do RPC wykorzystywane są wzorce Response Message Exchange Pattern i Request-Response Message Exchange Pattern, chociaż standard zezwala także na inne.

Zastosowanie

SOAP jest jednym z elementów pozwalającym na rozproszoną dystrybucję komponentów. Razem z technologiami takimi jak WSDL pozwala on na stworzenie rozbudowanego systemu podobnego do CORBA i DCOM. W rezultacie zostało to uczynione w Java 2 Enterprise Edition (gdzie SOAP występuje obok Java RMI) oraz platformie .NET, gdzie SOAP ma za zadanie całkowicie wyprzeć DCOM. Często też spotyka się tę technologię w aplikacjach webowych z racji wykorzystania typowych dla tej dziedziny technologii jak XML i HTTP. Trwają także prace nad standardem XUP, który jest czymś w rodzaju połaczenia SOAP i XUL. Zakłada on wykorzystanie SOAP do przekazywania informacji o zdarzeniach dotyczących interfejsu opartego na XML (na przykład wspomniany XUL).

Podsumowanie

SOAP jest niewątpliwie ciekawym protokołem, mimo że oparcie się na XML-u ogranicza jego wydajność. Co prawda trwają pracę nad technologiami takimi jak Binary XML, który pozwolą przyśpieszyć pracę z XML-em, lecz jak na razie w starciu wydajnościowym CORBA czy DCOM bez problemu są w stanie pokonać SOAP.

To co jest wadą jest także i zaletą, fakt, że SOAP opiera się na XML-u pozwala na wykorzystanie w nim wielu istniejących już technologii (chociażby XSLT czy algorytmy serializacji danych). Stawia on na modułowość i łatwość dostępu co niejednokrotnie jest ważniejsze od wydajności. Jednak niezależnie od tego, jest to bez wątpienia bardzo interesująca technologia.

Zupełnie inaczej rzecz się ma w przypadku systemów wbudowanych, a także wielu systemów czasu rzeczywistego. Tam mikrojądra odgrywają znacznie większą rolę. Jednym z popularniejszych systemów opartych na mikrojądrze jest QNX korzystający z jądra QNX Neutrino. Jego wewnętrzna architektura jest zupełnie inna od tej znanej z Linuksa czy też Uniksów. Wynika to głównie z tego, że nacisk jest położony na zupełnie elementy systemu. Jedną z najistotniejszych kwestii we wszystkich mikrojądrach jest komunikacja międzyprocesowa.

Wiadomości (messages)

Podobnie jak w innych systemach opartych na mikrojądrach, także w QNX tym co łączy wszystkie elementy systemu w jedną całość jest IPC. Podstawowym mechanizmem IPC udostępnianym przez QNX Neutrino są wiadomości (messages). Są to synchroniczne komunikaty na które adresat zawsze odpowiada. Warto przyjrzeć się sposobowi w jaki Neutrino przekazuje wiadomości.

• Wątek będący klientem wykonuje procedurę MsgSend(). Przechodzi on w stan SEND blocked, co jest równoważne jego wstrzymaniu. Jeżeli wątek będący adresatem czeka na wiadomość, jest on wznawiany automatycznie, bez udziału planisty.
• W momencie w którym wątek będący serwerem wywoła procedurę MsgReceive() dostanie on informację o otrzymanej wiadomości, a nadawca przejdzie w stan REPLY blocked. Jeżeli procedura MsgReceive() zostanie wywołana w sytuacji, kiedy nie ma żadnych wiadomości w kolejce do przetworzenia, wątek przejdzie w stan RECEIVE blocked i zostanie wstrzymany do momentu otrzymania wiadomości.
• Po wykonaniu operacji związanych z obsługą otrzymanego komunikatu, serwer wykonuję procedurę MsgReply(), która przekazuje klientowi odpowiedź lub MsgError(), która przekazuje informacje o błędzie. Obie te funkcje powodują przejście klienta w stan READY, a więc wznowienie jego działania.

Przesyłanie danych

Obok synchronizacji działania realizowanej przez przechodzenie wątków w różne stany drugą kwestią jest sam sposób przesłania danych. Jeżeli ilość przesyłanych danych jest niewielka (najczęściej poniżej 256 bajtów) są one buforowane w przestrzeni jądra i w ten sposób przenoszone między przestrzeniami adresowymi dwóch wątków. W przeciwnym razie Neutrino tymczasowo mapuje fragment przestrzeni adresowej serwera w przestrzeni klienta co pozwala na przeniesienie danych między nimi w bardzo wydajny sposób. Dzięki temu prędkość kopiowania wiadomości jest zależna jedynie od przepustowości pamięci operacyjnej urządzenia. Neutrino pozwala także na wysyłanie wiadomości złożonych z bloków o różnych rozmiarach rozmieszczonych w różnych obszarach przestrzeni adresowej.

Kanały (channels) i połączenia

W QNX Neutrino wątek, który chce otrzymywać wiadomości musi utworzyć kanał (channel). Nadawca, przed wysłaniem danych nawiązuje połączenie z tym kanałem. W przestrzeni użytkownika zarówno kanały jak i połączenia są reprezentowane przez liczby całkowite. Dodatkowo liczby identyfikujące połączenia używa się zamiennie z deskryptorami plików. Do każdego kanału przyporządkowane są trzy struktury danych przechowujące informacje o klientach.

• receive – bufor LIFO wątków oczekujących na wiadomość
• send – kolejka (FIFO) wątków, które wysłały jeszcze nieodebrane wiadomości
• reply – nieuporządkowana lista wątków, które wysłały wiadomość na którą nie udzielono jeszcze odpowiedzi

Podsumowanie

Oprócz wyżej wymienionych messages QNX wspiera także wiele innych rodzajów komunikacji międzyprocesowej. Są to sygnały, kolejki, pipes, pamięć dzielona, itp. Ich implementacja opiera się jednak głównie na messages, które to w najbardziej dobitny sposób przedstawiają cechy charakterystyczne QNX jeżeli chodzi o przesyłanie komunikatów. Wykorzystany został w nich przemyślany system synchronizacji, pozwalający uniknąć opóźnienia związanego z wywołaniem planisty CPU oraz mechanizm kopiowania danych wybierający optymalną metodę dla określonej ich ilości. Nie dziwi nacisk jaki położono właśnie na IPC, skoro jest to jeden z najważniejszych elementów mikrojądra QNX Neutrino.