konflikt procesów automatyzacji

Konflikt procesów automatyzacji to sytuacja, w której równolegle działające scenariusze wydają sprzeczne polecenia.

Jak powstaje konflikt równolegle uruchomionych zadań

Konflikt procesów automatyzacji występuje wtedy, gdy co najmniej dwa niezależne zadania wykonują operacje na tym samym zasobie, ale ich cele albo kolejność działań wzajemnie się wykluczają. Zasobem może być plik, katalog, rekord w lokalnej bazie danych, ustawienie programu, kolejka zadań, urządzenie USB albo usługa systemowa. Przykładowo jeden scenariusz może kopiować plik do katalogu roboczego, podczas gdy drugi w tym samym czasie usuwa pliki uznane za nieaktualne. Wynik zależy wtedy od dokładnego momentu wykonania poszczególnych instrukcji, a nie wyłącznie od ich poprawności zapisanej w konfiguracji.

Takie zachowanie jest przykładem problemu współbieżności. Jeżeli proces A odczyta stan zasobu, a następnie przygotuje zmianę, lecz przed jej zapisaniem proces B zmieni ten sam zasób, proces A może nadpisać nowsze dane starszą wartością. W systemach automatyzacji mówi się wówczas o wyścigu procesów, czyli race condition. Innym przypadkiem jest częściowo wykonana operacja: pierwszy scenariusz utworzy plik tymczasowy albo zmieni nazwę katalogu, a drugi potraktuje ten stan jako kompletny i rozpocznie dalsze działania na niegotowych danych.

Objawy wyścigu i wzajemnego nadpisywania zmian

Konflikt może objawiać się niestabilnie, dlatego samo jednorazowe powtórzenie operacji często nie wystarcza do potwierdzenia przyczyny. Typowe symptomy to sporadyczne komunikaty o zajętym pliku, powtarzające się uruchamianie tego samego zadania, znikające lub przywracane ustawienia, niepełne pliki wynikowe oraz różne rezultaty osiągane przy pozornie identycznych danych wejściowych. Jeżeli jeden proces czeka na zasób zablokowany przez drugi, pojawia się zakleszczenie, czyli deadlock. W takim stanie procesy pozostają aktywne, ale żaden nie może przejść do kolejnego etapu.

Do ustalenia przebiegu zdarzeń potrzebne są dzienniki zawierające co najmniej znacznik czasu, identyfikator zadania, nazwę operacji, używany zasób i rezultat. Sam wpis „operacja nie powiodła się” jest zbyt ogólny, ponieważ nie wskazuje, czy przyczyną był brak uprawnień, blokada pliku, przerwanie procesu, błędny warunek wejściowy czy równoległa modyfikacja. Przydatne jest porównanie kolejności wpisów z kilku dzienników. Jeżeli dwa procesy zapisują działania w różnych formatach czasu albo z opóźnieniem, logi mogą wymagać uporządkowania według wspólnego zegara systemowego i identyfikatorów uruchomień.

Blokady, kolejność działań i bezpieczne ponawianie

Podstawowym sposobem ograniczania konfliktów jest kontrolowanie dostępu do wspólnego zasobu. Blokada może mieć postać pliku sygnalizacyjnego, blokady udostępnianej przez system operacyjny albo mechanizmu dostępnego w konkretnym programie. Proces powinien utworzyć blokadę przed rozpoczęciem operacji, sprawdzić, czy blokada nie jest osierocona po wcześniejszym przerwaniu, a po zakończeniu zwolnić zasób. Sama obecność pliku blokady nie zawsze wystarcza, ponieważ po awarii może pozostać element nieodróżnialny od aktywnej blokady. Dlatego często zapisuje się w nim identyfikator procesu, czas utworzenia i nazwę zadania.

Ważna jest także idempotencja, czyli możliwość wielokrotnego wykonania tej samej operacji bez powodowania kolejnych, niepożądanych zmian. Przykładowo bezpieczniejsze jest zapisanie wyniku do nowego pliku tymczasowego, sprawdzenie jego kompletności i dopiero potem atomowa zmiana nazwy niż bezpośrednie nadpisywanie pliku używanego przez inny proces. Ponawianie operacji powinno następować tylko dla błędów przejściowych, takich jak chwilowa blokada, i powinno mieć ograniczoną liczbę prób oraz rosnące odstępy czasowe. Automatyczne powtarzanie każdego błędu może zwiększyć obciążenie i zwielokrotnić konflikt.

Diagnostyka automatyzacji na komputerze użytkownika

Sprawdzanie problemu warto rozpocząć od ustalenia, jakie programy, skróty, harmonogramy i usługi uruchamiają działania o podobnym celu. Należy porównać ich częstotliwość, warunki startowe, katalogi robocze oraz zakres modyfikowanych plików. W systemie Windows pomocne może być przejrzenie Harmonogramu zadań, Podglądu zdarzeń i dzienników aplikacji, a także sprawdzenie procesów działających w chwili wystąpienia błędu. Istotne jest odróżnienie procesu głównego od uruchomionych przez niego procesów potomnych, ponieważ dwa wpisy o podobnej nazwie mogą należeć do jednego łańcucha automatyzacji albo do odrębnych programów.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy problemach z niestabilnym działaniem automatyzacji można przeprowadzić diagnostykę środowiska systemowego oraz sprawdzić, czy przyczyną nie są błędy nośnika danych, uszkodzenia pamięci, nieprawidłowe działanie systemu lub przerwy w pracy komputera. Wnioski powinny wynikać z kolejności zdarzeń i powtarzalnych testów, a nie z samego faktu, że zadanie zakończyło się błędem. Po usunięciu przyczyny warto ponownie uruchomić każdy scenariusz osobno, a następnie sprawdzić ich współdziałanie w warunkach zbliżonych do normalnej pracy.