Czy semafory są efektywne w mikrokontrolerach? Analiza wydajności.

Semafory, czy ktoś tego w ogóle używa

Dziwne pytanie, ale bawię się w pisanie obsługi tych rzeczy na "wypasiony" mikrokontroler i naszły mnie wątpliwości.

Z jednej strony semafor sprawia że jakaś część kodu nie nadwyręża zasobów bo nie używa cykli CPU, z drugiej każde podniesienie semafora może spowodować ciągłe przełączanie kontekstu

Inaczej, sens jest wtedy kiedy nasz wątek w którym tego semafora używamy jest długi, albo kiedy nie jest często wywoływany.

Bo weźmy przypadek, wątek z semaforem 500 cykli, wątek główny odblokowujący 500 cykli, przełączanie kontekstu w jedną i drugą stronę 2 x 500 cykli :] i mamy 50 % wydajności systemu.


W sumie pisząc to, przyszło mi do głowy, że sens jeszcze jest kiedy semafor odblokowujący jest np w przerwaniu.

Szukasz dziury w całym. Jeśli dostęp do jakichś zasobów da się zrobić w jednym "kontekście" (tylko w wątku lub tylko w przerwaniu), to tak należy zrobić i błędem jest rozbijanie tego na dwa (lub więcej) "kontekstów" a następnie próba leczenia objawów ("przełączanie tego semafora zajmuje tak dużo czasu...") zamiast wyleczenia przyczyny. Jeśli zaś dostęp do jakiegoś zasobu musi być w dwóch wątkach i musi być zapewniona synchronizacja (albo poprzez wyłączny dostęp, czyli mutex, albo przez powiadomienie "innych", że dane są dostępne do przetwarzania, czyli semafor, kolejka, condition-variable itd.), to właśnie synchronizację trzeba zrobić jak należy, a nie cudować.

W ogóle to taka przypadłość liczenia cykli jest dosyć typowa dla ludzi od mikrokontrolerów, choć realnie jest to kompletnie bez sensu. Na "niewypasionym" mikrokontrolerze można sobie odpalić 10-20 wątków (to naprawdę dużo!) i realnie okazuje się, że przez większość czasu mikrokontroler i tak kręci się w wątku "idle" (pomijam oczywiście abstrakcyjne przypadki typu 20 wątków z których każdy liczy FFT). Zobacz sam - naliczyłeś że przełączenie kontekstu to 1 tysiąc cykli, a ten Twój "wypasiony" ukłąd ma jaki zegar? 500 MHz? No to w jedną sekundę tych cykli ma 500 milionów. Żeby przełączanie kontekstu stanowiło choć 10% obciążenia systemu musiałbyś ten kontekst zmieniać co 200 us. Masz naprawdę taką potrzebę? Jeśli nowe dane pojawiają się częściej, to przecież nie ma żadnego problemu - po to wymyślono buforowanie, kolejki, itd. Do tego nie wiem jakiego systemu używasz, ale w zwyczajnym RTOSie przełączenie kontekstu zwykle nie przekracza 200 cykli, jest więc ponad 2x szybsze niż to co założyłeś.

Pisząc program jednowątkowo - w postaci słynnego "superloop" faktycznie czasem te cykle trzeba liczyć, bo zanim układ dojdzie do robienia krytycznej czasowo czynności, to w najgorszym przypadku będzie musiał zrobić wszystkie inne, które krytyczne czasowo nie są. W przypadku RTOSa ten problem po prostu nie istnieje - w końcu od tego są priorytety.

Liczenie cykli to tylko przykładowa demonstracja problemu dla jego unaocznienia
A nie to czy on wystąpi praktycznie czy nie.

Właśnie sie nad tym zastanawiam, i pomyślałem że może ktoś podzieli się swoją opinią.

Tak mnie się zdaje, ale krytyczne czasowo rzeczy najczęściej zdarzają się od zdarzeń zewnętrznych. Pisząc program bez użycia systemu, zwykle używa się przerwań, ale one też nie zawsze muszą sprytnie rozwiązywać wszystkie problemy. Jak chociażby napływ nowych danych, z jednej strony być może trzeba je kolejkować z drugiej już obsługiwać.

Stąd właśnie pisałem o sensie używania ich w przerwaniu.
.

Chodzi o to, że mutex i semafor służą zasadniczo do czegoś zupełnie innego (choć jakby się uprzeć, to semafora można używać też w miejsce mutexa, ale licząc się z różnymi poważnymi problemami typu inwersja priorytetów). Dobrze by było więc sprecyzować o który dokładnie aspekt Ci chodzi, bo czym innym jest synchronizacja rozumiana jako "powiadomienie" (semafory), a czym innym wyłączny dostęp do współdzielonych zasobów (mutex).

Chętnie podyskutuję i przedstawię moje przemyślenia, jako że w zasadzie gdzieś od siedmiu lat piszę programy tylko wielowątkowo z RTOSem i moje podejście do liczenia cykli zmieniło się naprawdę diametralnie. Cała ta mania wydajności, liczenia cykli, bajtów RAMu, "ciężkości" i "powolności" programowania obiektowego w C++ itd. to na dzień dzisiejszy kompletne "urban legend" bez żadnego oparcia w faktach.

OK, racja, w sumie zmieniłem tytuł na same semafory. Bo na tym bardziej się skupiam w tej chwili. Jednak mutexy jakieś tam grosze dokładają, aby sobie nie zablokować programu w jakiś wypadkach niezbyt przemyślanych.

No to czemu uważasz, że korzyści wynikające z użycia semaforów nie przewyższają kosztów ich użycia? (; W życiu, w programowaniu, w elektronice, w inżynierii, ..., wszystko jest kompromisem, wydaje mi się jednak, że potencjalne koszty są mniejsze (znacząco) niż potencjalne korzyści. Jeśli koszty są duże, to pewnie dlatego, że starasz się np. odbierać dane po jednym bajcie - proste buforowanie (FIFO albo bufor kołowy albo cokolwiek + semafor) zdaje się rozwiązywać taki problem.

Wcale tak nie uważam, pisze że naszły mnie wątpliwości. Na komputerze PC często używam wątków choćby z powodu wygody Tylko tam jest relatywnie więcej mocy obliczeniowej. W słabszych sprzętach czasem trzeba sie zastanowić. Nie zawsze istnieje możliwość wzięcia mocniejszego mikrokontrolera.

trol.six napisał:

Na komputerze PC...

Jeśli porównujesz PC z "general-purpose operating system" do mikrokontrolera z RTOSem, to weź też poprawkę na to, że zaleta "relatywnie większej mocy obliczeniowej" jest skutecznie niwelowana choćby przez to, że przełączenie kontekstu w takim PC pewnie jest z wielokrotnie wolniejsze niż na RTOSie*, a do tego jeszcze niedeterministyczne, natomiast priorytety są dla takiego systemu tylko niezobowiązującą wskazówką.

* - w pierwszym lepszym artykule który znalazłem, ktoś napisał, że zmierzył czas przełączenia kontekstu w Linuxie na okolice 1.2 us. Artykuł jest z zeszłego roku, więc strzelmy że komputer miał procesor z zegarem 3 GHz. Wychodzi jakieś 3000-4000 cykli, wiec spokojnie 10x więcej niż w zwykłym RTOSie na mikrokontrolerze.

Zważywszy na wielkie ilości postów użytkowników semaforów coś jednak jest na rzeczy.

Freddie Chopin napisał:

Jeśli porównujesz PC z "general-purpose operating system" do mikrokontrolera z RTOSem, to weź też poprawkę na to, że zaleta "relatywnie większej mocy obliczeniowej" jest skutecznie niwelowana choćby przez to, że przełączenie kontekstu w takim PC pewnie jest z wielokrotnie wolniejsze niż na RTOSie*,

Relatywnie więcej nie znaczy lepiej czy szybciej tylko relatywnie na PC czasu rzędu 1ms są dla mnie w 95% akceptowalne, bo i linux to nie jest system czasu rzeczywistego, i główne problemy czasowe są na głowie systemu, i sterowników do niego. Weź 1000 cykli na przełączanie 1000 razy na sekunde. Przy 10MHz procka, masz 10% obciążenia i 9000000 cykli na wykorzystanie. Przy 100MHz już 1% i 99000000 cykli. Ba, nawet przy 10% masz 90000000.

Jak to tam działa sobie to nie wiem, ale przypuszczam że nie na semaforach. Z tego co widze wąskim gardłem okazuja się inne rzeczy.
.

trol.six napisał:

Zważywszy na wielkie ilości postów użytkowników semaforów coś jednak jest na rzeczy.

Semafory powinny służyć raczej do rozwiązywania pewnych problemów a nie ich tworzenia.