PLEX

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacja, szukaj

PLEX (ang. Programming Language for EXchanges) – strukturalny język wysokiego poziomu opracowany w Ericssonie. Służy do programowania central telefonicznych. Jest rozwijany od lat 70. XX wieku. Używany w centralach telefonicznych AXE Ericssona[1]. Występuje w dwóch odmianach. Na procesorach centralnych (Central Processor - CP) AXE wykorzystywana jest odmiana języka o nazwie Plex-C. Natomiast w modułach rozszerzeń EMRP 8-bitowa wersja Plex-M[2]. Projektantem języka był Göran Hemdahl[3].

Programy w PLEX-ie wykonywane są jako pewna liczba współbieżnych zadań, komunikujących się między sobą za pomocą zdarzeń nazywanych sygnałami. W rzeczywistości współbieżność ta jest pozorna. Zadania umieszczane są w jednej z czterech kolejek, o zrożnicowanym priorytecie i wykonywane sekwencyjnie[1].

Sygnały za pomocą których komunikują się zadania mogą być bezpośrednie lub buforowane. Sygnał bezpośredni można porównać do instrukcji skoku. Sygnały buforowane powodują utworzenie nowego zadania i umieszczenie go w kolejce. Sygnały można też podzielić, na pojedynczne (single) i łączone (combined). Sygnał łączony rozpoczyna zadanie, po wykonaniu którego sterowanie powraca do miejsca wywołania sygnału[1].

Język PLEX wbrew pozorom jest językiem dość niskiego poziomu i nie posiada mechanizmów zabezpieczających "system operacyjny" przed nieprawidłowo skonstruowanym oprogramowaniem. Stąd też na programiście spoczywa ciężar odpowiedzialności za pisanie kodu w zgodzie z wytycznymi producenta (opisanymi szczegółowo w dokumencie Design Rules). Istnieje wiele reguł z których najważniejszą jest nieprzekraczanie maksymalnego czasu obsługi pojedynczego sygnału (liczonego w instrukcjach kodu maszynowego) na danym poziomie wykonania (A, B, C, D). Przekroczenie maksymalnego czasu powoduje wymuszenie restartu centrali, co wiąże się z obniżeniem dostępności i jakości oferowanych usług. Wykonanie dłuższej sekwencji (np. budowanie tzw. Idle List w różnych blokach funkcjonalnych) musi być co pewien czas przerywane wysyłaniem sygnału CONTINUE, co umożliwia obsługę pozostałych sygnałów w kolejce. Drugą co do istotności regułą jest nieprzekraczanie maksymalnej ilości sygnałów wysłanych podczas obsługi pojedynczego sygnału przychodzącego. Naruszenie tej reguły może doprowadzić do przepełnienia kolejki sygnałów, co z kolei również prowadzi do restartu. Tego typu błąd jest trudny do wyśledzenia, gdyż występuje zwykle podczas silnego obciążenia centrali, a z faktu przepełnienia kolejki trudno jest wprost wywnioskować który blok został źle napisany.

Ciekawą cechą języka (wspieraną sprzętowo przez procesor centralny, CP) jest zdolność do kontrolowanego zwalniania zasobów w sytuacjach wyjątkowych, bez konieczności restartu centrali, tzw. FORLOPP (szw. förlopp -- przebieg zdarzeń). Procesor posiada specjalny rejestr FIR (Forlopp Register), który jest znacznikiem bieżącego "wątku" wykonania. Znacznik ten jest propagowany poprzez sygnały do wszystkich bloków programowych biorących udział w danej funkcjonalności. W każdym z bloków, alokowane zasoby są znakowane bieżącą zawartością rejestru FIR. Jeśli którykolwiek z bloków wykryje nieprawidłowy stan wykonania (np. otrzyma sygnał którego nie oczekiwał), może wywołać funkcję FLERROR i wszcząć procedurę anulowania "wątku" i zwalniania wszystkich zasobów z nim powiązanych. Dzięki temu, nie każda błędna sytuacja musi kończyć się restartem całego systemu, a jedynie selektywnym zwolnieniem zasobów. Inną odmianą kontroli wykonania wątku jest kontrola czasu wykonania zadania (nie należy mylić z czasem obsługi pojedynczego sygnału). Przykładem mogą być komendy wydawane przez operatora centrali. Funkcja FLAUDIT, znajdująca się na początku kodu obsługującego daną komendę, inicjuje monitorowanie czasu wykonania zadania (tu komendy operatora). Jeśli wykonanie potrwa dłużej niż podany czas maksymalny, dojdzie do automatycznego wygenerowania błędu FLERROR i zwolnienia zasobów. Ponieważ niektóre komendy mogą mieć bardzo zróżnicowany czas wykonania, istnieje możliwość programowego zwiększenia limitu czasu (funkcja FLEXTEND), jeśli przetwarzanie komendy tego wymaga. W przypadku pomyślnego zakończenia wykonania zadania, monitorowanie jest wyłączane funkcją FLRELEASE. Obsługą funkcjonalności FORLOPP zajmuje się blok Forlopp Manager (MFM).

Zobacz też[edytuj | edytuj kod]

Przypisy

  1. 1,0 1,1 1,2 Johan Erikson i Björn Lisper, Uniwersytet Mälardalen: A Formal Semantics for PLEX (ang.). [dostęp 7 marca 2009].
  2. Johan Erikson i Bo Lindell, Uniwersytet Mälardalen: The Execution Model of APZ/PLEX - An Informal Description (ang.). [dostęp 7 marca 2009].
  3. Joe Armstrong: A History of Erlang (ang.). [dostęp 7 marca 2009].