🚀 go-pugleaf

Witam

Maciej Sobczak wrote:

> oraz w systemach sterowania i RT. 

Z kolei w systemach RT ważne jest bezpieczeństwo, nie wiem czy procesy nie
dają lepszych gwarancji niż wątki. Np. mamy dwa sterowniki, jeden alarmowy,
który działa odcinając lub uruchamiając urządzenia do obsługi awarii. Drugi
jakiś wypasiasty sterownik, który robi to czy tamto, optymalizując,
adaptując, ... whatever. 
Teraz kiedy niechcący coś się pokopie w sterowniku wypasiastym, to
bezlitośnie zabijamy gada i koniec. Ale wiemy, że przynajmniej alarmowy
działa i on gwarantuje minimum zabezpieczeń. Jakby to były wątki jednego
procesu, to co? 

W sterownikach też ma sens część rzeczy separować w postaci osobnych
procesów, dopiero obsługę IO osadać na wątkach. Tak aby algorytmy nie
przeszkadzały w odbiorze informacji z zewnątrz i w wysyłaniu sterowania.
Ale tych watków nie będzie nie wiadomo ile. 

Np. Pewna firma chemiczna ma reaktory i tam mniej więcej występuje ok.
500-1000 zmiennych procesowych. Efektywnych sterowań "jest" gdzieś mniej
więcej 100 (mam nieaktualne dane). Czyli tych wątków też nie będzie
niewiadomo ile. Bo znowu bezsensu jest ustawiać na każdy czujnik jeden
wątek, również bezsensu jest ustawiać na każdy punkt sterowania jeden
wątek. 
Aktuatory i tak muszą mieć podstawową funkcjonalność zadaną na miejscu. Po
co więc ustalać aby jakiś wątek wykonywał tylko jedną banalną funkcję np.
set_flow(0.5). I tak set_flow(0.5) wysyła informację do aktuatora, który
nie zależnie od głównego sterownika ustawia przepływ półproduktu na 50%.
Tutaj rola sterownika sprowadza się do wysłania komunikatu
("set_flow",0.5). A samo wysyłanie komunikatów też lepiej grupować w
kolejki komunikatów, niż stosować zasadę obiekt+komunikat per wątek.

> W serwerach i systemach obliczeniowych nie jest to takie oczywiste.

To jest bardzo nieoczywiste :-).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/