pdziepak@quarnos.org
Implementacja nieblokujących struktur danych często stwarza problemy często niespotykane przy okazji opracowywania jakichkolwiek innych algorytmów. Całkowicie zasadnie, najpopularniejszymi przykładami w opracowaniach na ten temat jest problem ABA i jego pochodne. Oczywiście, do dnia dzisiejszego powstało wiele sposobów radzenia sobie z nim. Jednym z ciekawszych są tak zwane hazard pointers.
Blokady typu czytelnicy-pisarze są opisane chyba w każdym podręczniku traktującym o systemach operacyjnych czy synchronizacji dostępu do danych. Jest to proste rozwiązanie które jednak w praktyce nie okazało się być w pełni satysfakcjonujące. W wyniku prób pozbycia się pewnych wad tych blokad w Linuksie (i nie tylko) zagościły także dwie alternatywy tego rozwiązania: seqlocks i RCU.
FreeSpace is a 10-year-old game and despite the fact SCP developers have been doing great work since 2002 there are still many parts of code that were left unchanged. That means there is a great variety of antipatterns. Some of them are being solved while the others are so complex that their refactorization will require large amount of work. One of these antipatterns, easily found in FSO, is The Blob.
Jednym z głównych problemów związanych z wykorzystaniem garbage collectora jest możliwość dość drastycznego spadku wydajności w nieoczekiwanych momentach. Z tego powodu odśmiecanie pamięci zwykle nie może zostać zastosowane w systemach czasu rzeczywistego, a także w innych sytuacjach gdzie wydajność programu jest istotna. Twórcy systemu Inferno stworzyli algorytm Very Concurrent Garbage Collection (VCGC), którego zadaniem jest zminimalizowanie tych problemów.
Historia Uniksa sięga końca lat 60 XX wieku. Tymczasem wiele systemów operacyjnych wciąż opiera się na przyjętych w nim, często już nieaktualnych, założeniach. Oczywiście takie systemy jak Solaris czy rodzina *BSD wprowadzają dużo dodatkowych technologii, ale wciąż są w pewien sposób ograniczane przez swoich poprzedników i oparte na nich standardy.
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.
Jednym z niepożądanych zjawisk dość często pojawiających się przy tworzeniu aplikacji w oparciu o programowanie zorientowane obiektowo jest nadmierny rozrost metod. Najczęściej muszą one wykonać szereg dodatkowych operacji (sprawdzenie uprawnień, poprawności danych, logowanie czynności, itp.) zanim przystąpią do wykonywania głównego zadania. Często można sobie z tym poradzić uwzględniając takie ewentualności w projekcie aplikacji, zwykle nie jest to jednak idealne rozwiązanie. W tym celu powstała idea programowania zorientowanego aspektowo, które jest przystosowane właśnie do radzenia sobie z tego typu problemami.
Programowanie zorientowane obiektowo w czystym C, mimo że możliwe, rzadko kiedy jest proste i przyjemne, a powstały kod jest zwykle bardzo zagmatwany. Dlatego też na bazie C powstały kompatybilne z nim języki dodające wygodne w użyciu wsparcie dla kodu zorientowanego obiektowo. Pierwszy z nich to niezwykle popularny C++, w którym większość tych rozszerzeń to różnego rodzaju dodatkowe operacje wykonywane podczas kompilacji. Drugi to niszowy Objective-C, który (oprócz składni) od C++ różni się tym, że dodatkowe elementy jakie zostały do niego wprowadzone są odpowiednimi operacjami wykonywanymi podczas działania programu. Dzięki temu udaje się uzyskać w języku kompilowanym do kodu natywnego część udogodnień znanych z technologii takich jak .NET czy Java.
Programowanie zorientowane obiektowo jest niewątpliwie jednym z najpopularniejszych obecnie paradygmatów. Powstało bardzo wiele opracowań na jego temat wprowadzających chociażby techniki znane jako wzorce projektowe. Nie jest to jednak rozwiązanie idealne i w pewnych zastosowaniach wiążą się z nim pewne trudności. Chodzi tutaj o tworzenie gier komputerowych gdzie coraz częściej można się spotkać z programowaniem opartym na komponentach.
Głównym sposobem wspierania polimorfizmu w prawie wszystkich popularnych implementacjach C++, a także innych języków programowania, jest korzystanie z tablic funkcji wirtualnych vtables. Wiążą się z tym jednak pewne nieudogodnienia. Funkcje szablonowe nie mogą być jednocześnie funkcjami wirtualnymi, jest to co prawda całkiem logiczne, ale z drugiej strony czasami staje się problemem. Tego typu trudności można łatwo pokonać korzystając z poprzednio opisanych thin templates. Zupełnie inną klasą problemów jest narzut związany z wywoływaniem funkcji wirtualnych, a także sama obecność vtables, które przy rozbudowanych klasach mogą osiągnąć pokaźne rozmiary. Sposobem na pozbycie się spadku wydajności spowodowanego dynamiczną obsługą mechanizmu, także i w tej sytuacji jest statyczny sposób rozwiązania problemu. Warto zapoznać się ze statycznym polimorfizmem znanym także jako simulated dynamic binding.
Jednym z najbardziej oczywistych zastosowań szablonów jest implementacja różnego rodzaju struktur danych. Zostało to wykorzystane na szeroką skalę w bibliotekach takich, jak chociażby STL. Z szablonami wiążą się jednak pewne problemy, które nie zawsze ujawniają się na architekturze x86, ale są dużą przeszkodą w przypadku systemów wbudowanych. Chodzi tutaj głównie o nadmierny wzrost objętości plików binarnych. Jednym ze sposobów na poradzenie sobie z tym jest zastosowanie idiomu thin template.