Rurociąg (oprogramowanie) - Pipeline (software)

Ten artykuł dotyczy ogólnie potoków oprogramowania. Aby zapoznać się z oryginalną implementacją powłok, zobacz Pipeline (Unix) .

W inżynierii oprogramowania , A rurociągu składa się z łańcucha z elementów do przetwarzania ( procesów , nici , współprogram , funkcji , etc. ), rozmieszczone w taki sposób, że sygnał wyjściowy każdego elementu jest wejściem następnego; nazwa jest analogiczna do fizycznego potoku . Zwykle pewna ilość buforowania jest zapewniona między kolejnymi elementami. Informacje, które płynie w tych rurociągach jest często strumień z ewidencji , bajtów lub bitów i elementy rurociągu można nazwać filtry ; Nazywa się to również wzorcem projektowym rur i filtrów . Łączenie elementów w rurociąg jest analogiczne do zestawienia funkcji .

Mówiąc w skrócie, rurociąg jest liniowy i jednokierunkowy, chociaż czasami termin ten jest stosowany do bardziej ogólnych przepływów. Na przykład, pierwotnie jednokierunkowy potok może mieć pewną komunikację w drugim kierunku, znanym jako kanał zwrotny lub kanał zwrotny, jak w hacku lexer , lub rurociąg może być w pełni dwukierunkowy. Przepływy z jednokierunkowym drzewem i ukierunkowanymi topologiami acyklicznych grafów zachowują się podobnie do (liniowych) potoków - brak cykli czyni je prostymi - i dlatego można je luźno nazywać „potokami”.

Realizacja

Potoki są często wdrażane w wielozadaniowym systemie operacyjnym , uruchamiając wszystkie elementy w tym samym czasie co procesy i automatycznie obsługując żądania odczytu danych przez każdy proces z danymi zapisanymi przez proces nadrzędny - można to nazwać potokiem wieloprocesowym. W ten sposób procesor będzie w naturalny sposób przełączany między procesami przez program planujący , aby zminimalizować jego czas bezczynności. W innych typowych modelach elementy są implementowane jako lekkie wątki lub jako procedury w celu zmniejszenia obciążenia systemu operacyjnego często związanego z procesami. W zależności od systemu operacyjnego wątki mogą być planowane bezpośrednio przez system operacyjny lub przez menedżera wątków. Coroutines są zawsze planowane przez odpowiedniego kierownika.

Zwykle żądania odczytu i zapisu są operacjami blokującymi, co oznacza, że ​​wykonywanie procesu źródłowego po zapisaniu jest zawieszone do momentu, gdy wszystkie dane mogą zostać zapisane w procesie docelowym, podobnie jak wykonanie procesu docelowego po odczytaniu, jest zawieszona do czasu, gdy przynajmniej część żądanych danych będzie mogła zostać uzyskana z procesu źródłowego. Nie może to prowadzić do zakleszczenia , w którym oba procesy czekałyby w nieskończoność na wzajemną odpowiedź, ponieważ co najmniej jeden z dwóch procesów wkrótce zostanie obsłużony przez system operacyjny i będzie kontynuował działanie.

Aby zwiększyć wydajność, większość systemów operacyjnych implementujących potoki używa buforów potoków , które umożliwiają procesowi źródłowemu dostarczenie większej ilości danych, niż proces docelowy może obecnie lub chce odebrać. W większości systemów operacyjnych uniksowych i uniksopodobnych dostępne jest również specjalne polecenie, które implementuje bufor potoku o potencjalnie znacznie większym i konfigurowalnym rozmiarze, zwykle nazywany „buforem”. To polecenie może być przydatne, jeśli proces docelowy jest znacznie wolniejszy niż proces źródłowy, ale mimo wszystko pożądane jest, aby proces źródłowy mógł zakończyć swoje zadanie tak szybko, jak to możliwe. Np. Jeśli proces źródłowy składa się z polecenia, które odczytuje ścieżkę audio z płyty CD, a proces docelowy składa się z polecenia, które kompresuje dane audio w postaci fali do formatu takiego jak MP3 . W takim przypadku buforowanie całej ścieżki w buforze potokowym umożliwiłoby szybsze zatrzymanie napędu CD i umożliwiłoby użytkownikowi wyjęcie płyty CD z napędu przed zakończeniem procesu kodowania.

Takie polecenie bufora można zaimplementować za pomocą wywołań systemowych do odczytu i zapisu danych. Marnotrawstwem zajęte oczekujących można uniknąć za pomocą urządzeń takich jak ankiety lub wybierz lub wielowątkowość .

Niektóre godne uwagi przykłady systemów oprogramowania potokowego obejmują:

VM / CMS oraz z / OS

CMS Pipelines to przeniesienie pomysłu na potok do systemów VM / CMS i z / OS . Obsługuje znacznie bardziej złożone struktury potoków niż powłoki Unix, z krokami obejmującymi wiele strumieni wejściowych i tworzącymi wiele strumieni wyjściowych. (Taka funkcjonalność jest obsługiwana przez jądro Uniksa, ale niewiele programów używa jej, ponieważ powoduje to skomplikowaną składnię i tryby blokowania, chociaż niektóre powłoki obsługują ją poprzez przypisanie dowolnego deskryptora pliku ).

Tradycyjne aplikacje w systemach operacyjnych komputerów mainframe IBM nie mają standardowych strumieni wejściowych i wyjściowych umożliwiających przekierowanie lub potokowanie. Zamiast odradzania procesów za pomocą programów zewnętrznych, CMS Pipelines oferuje lekki dyspozytor do jednoczesnego wykonywania instancji wbudowanych programów w celu uruchomienia potoku. Ponad 200 wbudowanych programów, które implementują typowe narzędzia UNIX oraz interfejs do urządzeń i usług systemu operacyjnego. Oprócz programów wbudowanych CMS Pipelines definiuje strukturę umożliwiającą pisanie przez użytkownika programów w języku REXX ze strumieniami wejściowymi i wyjściowymi, które mogą być używane w potoku.

Dane na komputerach mainframe IBM zazwyczaj znajdują się w systemie plików zorientowanym na rekord, a podłączone urządzenia we / wy działają w trybie nagrywania, a nie w trybie strumieniowym. W konsekwencji dane w CMS Pipelines są obsługiwane w trybie nagrywania. W przypadku plików tekstowych rekord zawiera jeden wiersz tekstu. Ogólnie rzecz biorąc, CMS Pipelines nie buforuje danych, ale przekazuje rekordy danych w sposób blokowany z jednego programu do drugiego. Zapewnia to deterministyczny przepływ danych przez sieć połączonych ze sobą rurociągów.

Rurociągi obiektowe

Oprócz potoków opartych na strumieniu bajtów istnieją również potoki obiektowe. W potoku obiektowym przetwarzanie elementów wyjściowych obiektów zamiast tekstu. Program Windows PowerShell zawiera wewnętrzny potok obiektów, który przesyła obiekty .NET między funkcjami w środowisku wykonawczym programu PowerShell. Kanały , które można znaleźć w języku programowania Limbo, są innymi przykładami tej metafory.

Potoki w GUI

Z potoków korzystają również środowiska graficzne, takie jak RISC OS i ROX Desktop . Zamiast udostępniać okno dialogowe zapisywania zawierające menedżera plików, które pozwala użytkownikowi określić, gdzie program powinien zapisywać dane, RISC OS i ROX zapewniają okno dialogowe zapisywania zawierające ikonę (i pole do określenia nazwy). Miejsce docelowe określa się, przeciągając i upuszczając ikonę. Użytkownik może upuścić ikonę w dowolnym miejscu, w którym można upuścić już zapisany plik, w tym na ikony innych programów. Jeśli ikona zostanie upuszczona na ikonę programu, zostanie załadowana, a zawartość, która w przeciwnym razie zostałaby zapisana, jest przekazywana do standardowego strumienia wejściowego nowego programu.

Na przykład użytkownik przeglądający sieć WWW może natrafić na skompresowany obraz .gz, który chce edytować i ponownie przesłać. Korzystając z potoków GUI, mogli przeciągnąć łącze do programu do archiwizacji, przeciągnąć ikonę przedstawiającą wyodrębnioną zawartość do ich edytora obrazów , edytować ją, otworzyć okno dialogowe Zapisz jako i przeciągnąć jego ikonę do oprogramowania do przesyłania.

Koncepcyjnie ta metoda może być używana z konwencjonalnym oknem dialogowym zapisywania, ale wymagałoby to od programów użytkownika posiadania oczywistej i łatwo dostępnej lokalizacji w systemie plików, do której można przejść. W praktyce często tak nie jest, więc potoki GUI są rzadkie.

Inne uwagi

Nazwa „rurociąg” wywodzi się z przybliżonej analogii z fizyczną instalacją wodno-kanalizacyjną, w której rurociąg zwykle umożliwia przepływ informacji tylko w jednym kierunku, tak jak woda często płynie w rurze.

Potoki i filtry można postrzegać jako formę programowania funkcjonalnego , wykorzystując strumienie bajtów jako obiekty danych; Bardziej szczegółowo, mogą być postrzegane jako szczególnej postaci monadzie do I / O .

Koncepcja rurociągu jest również kluczowe dla Cocoon tworzenie stron internetowych ram lub jakiejkolwiek XProc (standardami W3C) wdrożeniach, gdzie pozwala strumień źródło zostać zmienione przed ostatecznym wyświetlaczu.

Ten wzorzec zachęca do używania strumieni tekstowych jako danych wejściowych i wyjściowych programów. Ta zależność od tekstu musi być uwzględniona podczas tworzenia powłok graficznych do programów tekstowych.

Zobacz też

Uwagi

  1. ^ Istnieją wyjątki, takie jak sygnały „przerwanej rury”.
  2. ^ "Monadic I / O i programowanie powłoki UNIX" .

Linki zewnętrzne