On 2013-10-10 18:43, Sebastian Biały wrote:
> On 2013-10-10 18:23, JDX wrote:
>>> Na Microchipa nie. Na *dowolny* podam do znudzenia ten sam co zawsze:
>> Dowolny? To cli() i sei() to są standardowe funkcje C++ (i C)? :-D
>
> Odróżniasz idiom RAII od kodu natywnego, prawda?
Ale o co chodzi? Co ma RAII do kodu natywnego? W każdym razie chodziło
mi jedynie o to, że cli() i sei() to nie są funkcje standardowe C czy
też C++.

>> tak
>> zaimplementowanej sekcji krytycznej IMO *nie jest* lepsze.
>
> Zdefiniuj najlepsze.
>
>> IMO lepsza
>> jest "ręczna" kontrola nad CS ponieważ tak w ogólności to chcemy jak
>> najszybciej odblokować przerwania
>
> To nie jest prawda. Czasem chcemy mieć pewność że UART_D zostanie
> odczytany jeszcze w sekcji krytycznej. Efektem czego jest workaround z
> temp w C. Nie ma rozwiązań załatwiających wszystkie przypadki. To jest
> rozwiązujące pewna sporą grupę czestych sytuacji w przerwaniach.
No to przecież sam pokazałeś że w C obudowujemy czytanie w cli()/sei().
A jeśli z jakiegoś powodu w tej samej funkcji potrzebujemy przeczytać
zasób jeszcze raz, no to jeszcze raz obudujemy operację czytania. Zdaję
sobie sprawę, że kod się komplikuje i tym samym jest bardziej podatny na
błędy, ale w sam raz IMO w tak, nomen omen, krytycznych przypadkach jak
CS lepiej jest sterować ręcznie a nie zdawać się na automatykę.

>> a nie czekać do momentu wyjścia z
>> funkcji gdy zawołany zostanie destruktor.
>
> Destruktor nie "czeka" tylko wołany jest natychmiast po return.
> Dokładnie tak jak chcę.
Zakładając, że pomiędzy odczytaniem z chronionego zasoby a returnem nie
ma znaczącego (w sensie czasu wykonania) kodu.

>> No i IMO tak zaimplementowana
>> CS może prowadzić do jeszcze większych i trudniejszych do wykrycia
>> ooops-ów jeśli ktoś będzie tworzycł CS na początku jakiejś dużej funkcji.
>
> Taki idiom daje znacznie wieksze gwarancje w dobrze zrobionym kodzie. W
> kodzie napisanym byle jak czyli z wielkimi funkcjami - nic nie daje
> gwarancji poza modlitwą. Subiektywnie patrząc: RAII genaruje mniej
> błedów niż jego ręczna emulacja i miałem w życiu na to milion przykładów.
W każdym razie ja w podanym przykładzie jakoś nie widzę wyższości C++
nad C. Zyskujesz większą odporność na błędy ale płacisz za to mniej
precyzyjną kontrolą nad CS. Nie twierdzę, że C++ jest gorsze od C w
zastosowaniach embedded. Twierdzę jedynie, że przykład jest słaby.

>> No i przydało by sie też jakieś info na temat tego co to jest
>> UART_D - domyślam się, że jest to jakiś rejestr zmieniany
>> (asynchronicznie) przez moduł UART-ów.
>
> To jest coś chronione przez sekcję krytyczna. Nie ma znaczenia co to
> jest. Probolemem wielu programistów embedded jest wlasnie to że *musza*
> wiedzieć co to jest, choć wiedza taka zazwyczaj kończy się pisaniem
> nieprzenośnego kodu.
No nie wiem, mi w sam raz wystarczyłaby informacja, że to jest coś co ma
być chronione za pomocą CS. Tak, abym nie musiał snuć domysłów. :-)