Mutexy API

[bambuchaAdm]

Na potrzeby dalszej części, przytoczę sygnatury take z brancha mutex. Jestem świadom że nie jest to skończone, służą tylko na potrzeby poniższych rozważań.

void mutex::take()
void mutex::take(uint32_t timeout)

Z punktu widzenia RTOSa sam mutex.take() jest bardzo słaby. Nie jest z góry ograniczone ile będzie się taki call wykonywał. Tak więc sądzę, że jest on nie potrzebny. Wystarczy dać programiście narzędzia do zrobienia takiego konstruktu np. w postaci nieskończonego timeoutu j. Zmniejszy to ilość błędów w programach.

Jest inna rzecz o której trzeba ładnie pomyśleć. Powiedzmy mamy taki call mutex.take(200). Jeżeli wszystko jest w porządku to świetnie, po prostu wychodzimy z take() i działamy dalej.

Jajo zaczyna się, gdy ten timeout nastąpił. Fajnie byłoby gdyby wołający miał informację, czy powrót sterowania jest spowodowany poprawnym daniem mutexu czy błąd spowodowany przekroczeniem.

Najprostszym rozwiązaniem tego problemu byłoby dodanie kodu wyjścia. Wtedy sygnatura wyglądałby uint8_t mutex::take(uint32_t timeout) oraz użycie mniej więcej tak:

if(mutex.take(200) == FINE){
   // Gdy mutex wykonał się poprawnie
} else {
   // Gdy nastąpił timeout
}

Takie podejście spowoduje dużą ilość ifowania w kodzie oraz ewentualnie jego zaciemnie. Jednak jest najprostrzym do implementacji i będzie działał. Na pewno użyjemy tego.

Drugim pomysłem jest użycie wskaźnika na funkcję która zostanie wywołana jeżeli wystąpi timeout. Problem jest jak sterowanie ma wrócić do taska i czy w ogóle powinno. Bardziej bym szedł w tę stronę, ale wymaga to większego przemyślenia w kontekście systemu.

[ggajoch]

co do zwracania czy udało się wziąć czy nie - owszem, zgadzam się jak najbardziej, nie dopisałem tego.
Jeśli chodzi o timeout nieskończony - z doświadczenia wiem że jeśli:
a) damy że nic nie ma czasu nieskończonego to będzie się to kończyć rozwiązaniami w stylu:
while(!mutex.take(0xFFFFFFFF));
b) jeśli damy argument nieskończony to większość wywołań będzie takich właśnie.
mutex.take(TIME_INF)
//większość wywołań dostępu blokującego do sprzętu nie powinno mieć timeouta - chyba że jest on zamierzony, a wtedy po prostu dajemy argument...

dlatego proponuję pozostawić wywołanie mutex.take() - ono będzie tak napisane że potem można jego ciało przenieść do drugiego - po prostu jako wyifowany przypadek.