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]. Jest 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ę pomię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 oraz wykonywane sekwencyjnie^[1].

Sygnały za pomocą których komunikują się zadania bywają bezpośrednie albo buforowane. Sygnał bezpośredni da się porównać do instrukcji skoku. Sygnały buforowane powodują założenie nowego zadania oraz umieszczenie go w kolejce. Sygnały da się też podzielić, na pojedynczne (single) oraz łą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 nader niskiego poziomu oraz nie ma 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 oraz jakości oferowanych usług. Wykonanie dłuższej sekwencji (np. budowanie tzw. Idle List w wielorakich blokach funkcjonalnych) musi być co pewien czas przerywane wysyłaniem sygnału CONTINUE, co dopuszcza obsługę pozostałych sygnałów w kolejce. Drugą najważniejszą 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 także prowadzi do restartu. Tego typu błąd jest trudny do wyśledzenia, albowiem jest zwykle podczas silnego obciążenia centrali, a z faktu przepełnienia kolejki trudno jest wprost wywnioskować który blok stał się ź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 (FORLOPP). Procesor ma 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 oraz wszcząć procedurę anulowania "wątku" oraz 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 zaledwie selektywnym zwolnieniem zasobów. Inną odmianą kontroli wykonania wątku jest kontrola czasu wykonania zadania (nie trzeba mylić z czasem obsługi pojedynczego sygnału). Przykładem bywają 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 oraz zwolnienia zasobów. Gdyż pewne komendy potrafią posiadać 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).

Sprawdź też

• Erlang

Przypisy