Pułapka systemu asynchronicznego
Pułapka systemu asynchronicznego ( AST ) odnosi się do mechanizmu stosowanego w kilku komputerowych systemach operacyjnych zaprojektowanych przez dawną firmę Digital Equipment Corporation (DEC) z Maynard w stanie Massachusetts .
Mechanizm
Różne zdarzenia w tych systemach mogą być opcjonalnie sygnalizowane z powrotem do procesów użytkownika za pośrednictwem mechanizmu AST. Te AST działają jak wywołania podprogramów, ale są dostarczane asynchronicznie , to znaczy bez względu na kontekst głównego wątku. Z tego powodu należy zadbać o:
- aby upewnić się, że każdy kod, który jest współdzielony między głównym wątkiem a AST, musi być zaprojektowany tak, aby był ponownie wprowadzany , oraz
- wszelkie udostępniane dane muszą być zabezpieczone przed uszkodzeniem, jeśli zostaną w dowolnym momencie zmodyfikowane przez AST. W przeciwnym razie dane muszą być chronione przez blokowanie AST w krytycznych sekcjach .
AST są najczęściej spotykane w wyniku wydawania wywołań QIO do jądra . Zakończenie I/O może być zasygnalizowane przez wydanie AST dla wywołującego procesu/zadania. Niektóre błędy w czasie wykonywania mogą być również sygnalizowane za pomocą mechanizmu AST. W OpenVMS specjalne AST trybu jądra są używane jako standardowy mechanizm uzyskiwania stosunkowo wygodnego dostępu do kontekstu procesu (w tym stronicowania procesu do pamięci fizycznej, jeśli jest to potrzebne). Te typy AST są wykonywane z najwyższym możliwym priorytetem na proces następnym razem, gdy program planujący uczyni ten proces aktualnym i są używanemiędzy innymi do pobierania informacji na poziomie procesu (w odpowiedzi na system $GETJPI "getjob/process information" call) oraz do usunięcia procesu.
Następujące systemy operacyjne implementują AST:
AST są z grubsza analogiczne do sygnałów uniksowych . Istotne różnice to:
- Nie ma „kodów sygnału” przypisanych do AST: zamiast przypisywania obsługi do kodu sygnału i podnoszenia tego kodu, AST jest określany bezpośrednio przez jego adres. Pozwala to na jednoczesne oczekiwanie dowolnej liczby AST (z zastrzeżeniem limitów przetwarzania).
- AST nigdy nie przerywają żadnego trwającego wywołania systemowego . W rzeczywistości proces może przejść w stan „hibernacji” (za pomocą wywołania systemowego $HIBER) lub czekać na flagę zdarzenia, wywołując np. dostarczony. Po dostarczeniu AST (wyzwolonego zakończeniem we/wy, zegarem lub innym zdarzeniem) proces jest tymczasowo wyłączany z oczekiwania na wykonanie AST. Po zakończeniu procedury AST ponownie wykonywane jest wywołanie, które wprowadziło proces w stan hibernacji lub oczekiwanie na flagę zdarzenia; w istocie przyczyna oczekiwania jest ponownie oceniana. Jedynym sposobem wyjścia z tej pętli (oprócz usunięcia procesu) jest wykonanie wywołania systemowego $WAKE lub $SETEF w celu zaspokojenia oczekiwania. Może to zrobić sam proces, wywołując $WAKE lub $SETEF w AST lub (jeśli używana jest globalna flaga zdarzenia) $SETEF w innym procesie.
VAX/VMS V4 i późniejsze wdrożyły interesującą optymalizację problemu synchronizacji między kodem na poziomie AST i innym niż AST. Usługa systemowa o nazwie $SETAST mogłaby zostać wykorzystana do wyłączenia lub włączenia dostarczania AST dla obecnych i wszystkich mniej uprzywilejowanych trybów dostępu (termin OpenVMS dla funkcji bezpieczeństwa opartych na pierścieniu ). Jeśli jednak sekcja krytyczna wymagająca ochrony przed AST miała tylko kilka instrukcji, wówczas narzut związany z wykonywaniem wywołań $SETAST mógłby znacznie przewyższyć czas wykonania tych instrukcji.
Tak więc tylko dla trybu użytkownika (najmniej uprzywilejowany pierścień, zwykle używany przez zwykłe programy użytkownika) dostarczono parę flag bitowych w predefiniowanej lokalizacji pamięci do zapisu przez użytkownika (w przestrzeni „P1” na proces). Znaczenie tych dwóch flag można interpretować jako „nie dostarczaj żadnych AST” i „AST zostały wyłączone”. Zamiast zwykłej pary wywołań $SETAST, kod trybu użytkownika ustawiałby pierwszą flagę przed wykonaniem sekwencji instrukcji, podczas których AST muszą być blokowane, i usuwał ją po sekwencji. Następnie (zwróć uwagę na kolejność tutaj, aby uniknąć warunków wyścigu ) sprawdzi drugą flagę, aby zobaczyć, czy została ustawiona w tym czasie: jeśli tak, to AST naprawdę zostały wyłączone i należy wywołać $ SETAST, aby je ponownie włączyć . W najczęstszym przypadku żadne AST nie staną się oczekujące w tym czasie, więc w ogóle nie będzie potrzeby wywoływania $SETAST.
Z kolei kod dostarczania AST jądra sprawdzałby pierwszą flagę przed próbą dostarczenia AST w trybie użytkownika; gdyby był ustawiony, to bezpośrednio ustawiałby bit wyłączony AST w bloku sterowania procesem (ten sam bit, który byłby ustawiony przez jawne wywołanie $SETAST z trybu użytkownika), a także ustawiałby drugą flagę przed powrotem i wyjściem AST niedostarczony.
Podobnym mechanizmem jest mechanizm wywoływania procedur asynchronicznych w systemach operacyjnych z rodziny Windows NT .
Dalsza lektura
- Elementy wewnętrzne OpenVMS Alpha i struktury danych: planowanie i kontrola procesu: wersja 7.0, Ruth Goldenberg, Saro Saravanan, Denise Dumas, ISBN 1-55558-156-0