On Mon, 11 Feb 2019 10:02:24 +0100, Grzegorz Niemirowski wrote:
>> Może należało by sprawdzić najpierw jedną połówkę, później drugą i
>> ponownie pierwszą, dla pewności.
>
> Można.

Niby można, ale to dalej będzie lichota, bo nic nie gwarantuje, że przy
trzecim sprawdzaniu BAM! znów interrupt nie strzeli.
Ktoś mógłby powiedzieć "no tak, ale to przerwanie wyzwala się raz na
jakiś czas, kilka cykli CPU to za krótko by dwa razy zdążyło się
wyzwolić" - ale to nie do końca słuszne założenie. Może być tak, że
uruchomi się nasze przerwanie, zaraz za nim jakieś obce przerwanie które
robi coś dłuuuugo i zaraz po nim znów wraca to nasze, z nowym (złośliwie
ustawionym) DEL_STEP.

> Można też zastosować sekcję krytyczną czyli wyłączyć przerwania
> na moment testu.

To tak. Ale moje skromne i niezobowiązujące zdanie jest takie, że z
_disable() należy obchodzić się tak jak z goto. Są przypadki gdzie można
się tym pokusić bo coś uprości i będzie wszystkim żyło się lepiej, ale
jeśli tylko można - lepiej unikać, bo potem człowiek się uzależni i
zacznie produkować potworki. No i oczywiście wyłączenie przerwań
poskutkuje tym, że ich wykonywanie obarczone będzie jitterem (bo przy
dłuższych sprawach przerwania nam się zakolejkują) - a to może być, w
niektórych zastosowaniach/warunkach, jakimś problemem. Do tego takie
ręczne wyłączanie przerwań wprowadza stan, o którym należy pamiętać (tj.
nie zapomnieć o włączeniu przerwań z powrotem) - przy większym codeflow
który może różnymi ścieżkami pobiec łatwo robi się wtedy mętlik.

Mateusz