Jaka jest różnica między busy-wait a ankietami?

Załóżmy, że mamy mikroprocesor lub mikrokontroler, który ma wykonać jakąś akcję, gdy zauważy, że przycisk jest wciśnięty.

Pierwszym podejściem jest, aby program wszedł w pętlę, która nie robi nic poza spojrzeniem, aby sprawdzić, czy Przycisk się zmienił, a gdy już się zmieni, wykonaj wymaganą akcję.

Drugim podejściem w niektórych przypadkach byłoby zaprogramowanie sprzętu do wyzwalania przerwania po naciśnięciu przycisku, zakładając, że przycisk jest podłączony do wejścia, które jest przewodowy, więc może spowodować przerwanie.

Trzecim podejściem jest skonfigurowanie timera, aby przerywał procesor z pewną szybkością (powiedzmy 1000x / sekundę) i aby obsługa tego przerwania sprawdzała stan przycisku i działała na niego.

Pierwsze podejście wykorzystuje busy-wait. Może oferować bardzo dobry czas reakcji na jeden konkretny bodziec, kosztem całkowitego dostrojenia wszystkiego innego. Drugie podejście wykorzystuje przerwanie wywołane zdarzeniami. Często będzie oferował nieco wolniej czas reakcji niż busy-waiting, ale pozwoli procesorowi na wykonywanie innych czynności podczas oczekiwania na wejście/wyjście. może również pozwolić procesorowi przejść w tryb uśpienia o niskiej mocy, dopóki przycisk nie zostanie naciśnięty. Trzecie podejście będzie oferować czas reakcji, który jest znacznie gorszy od pozostałych dwóch, ale będzie użyteczny nawet jeśli sprzęt nie pozwoli na wywołanie przerwania przez naciśnięcie przycisku.

W przypadkach, gdy wymagana jest szybka reakcja, często konieczne będzie użycie albo wyzwalanego zdarzenia przerywać lub zajęty-czekać. W wielu przypadkach jednak podejście ankietowane może być najbardziej praktyczne. Sprzęt może nie istnieć, aby obsługiwać wszystkie zdarzenia, które mogą być zainteresowane, lub liczba zdarzeń, które są zainteresowane, może znacznie przekroczyć liczbę dostępnych przerwań. Ponadto może być pożądane, aby niektóre warunki generowały opóźnioną odpowiedź. Załóżmy na przykład, że chcemy policzyć liczbę aktywacji przełącznika, z zastrzeżeniem następujących kryteria:

1. każde uzasadnione Zdarzenie przełącznika będzie składać się z interwału od 0 do 900us (mikrosekund), podczas którego przełącznik może dowolnie zamykać się i otwierać, po którym następuje interwał co najmniej 1,1 ms, podczas którego przełącznik pozostanie zamknięty, po którym następuje interwał od 0 do 900us, podczas którego przełącznik może dowolnie otwierać i zamykać, po którym następuje interwał co najmniej 1,1 ms, podczas którego przełącznik będzie otwarty.
2. oprogramowanie musi ignorować stan przełącznik dla 950us po każdym nieodebranym otwarciu lub zamknięciu przełącznika.
3. oprogramowanie może dowolnie liczyć lub ignorować zdarzenia przełącznika, które występują poza wymaganym interwałem wygaszania, ale trwają krócej niż 1,1 ms.
4. liczba zgłoszonych programów musi być ważna w ciągu 1,99 ms od czasu, gdy przełącznik jest stabilny "zamknięty".

Najprostszym sposobem na wyegzekwowanie tego wymogu jest obserwacja stanu przełącznika 1000 x / sekundę; jeśli jest on widziany jako "zamknięty", gdy poprzedni stan był "otwarty", zwiększ licznik. Bardzo proste i łatwe; nawet jeśli przełącznik otwiera się i zamyka na różne dziwne sposoby, podczas 900us poprzedzającego i następującego po prawdziwym wydarzeniu, oprogramowanie nie będzie się przejmować.

Możliwe byłoby użycie przerwania wyzwalanego przełącznikiem wraz z timerem, aby uzyskać szybszą odpowiedź na wejście przełącznika, przy jednoczesnym spełnieniu wymaganego wymogu wygaszania. Początkowo wejście będzie uzbrojone, aby uruchomić następnym razem, gdy przełącznik się zamknie. Once the przerwanie zostało uruchomione, oprogramowanie wyłączyło je, ale ustawiło timer, aby wyzwolić przerwanie po 950us. Po wygaśnięciu timera uruchamiane będzie przerwanie, które uzbroi przerwanie, aby odpalić następnym razem, gdy przełącznik zostanie "otwarty". Przerywanie to z kolei wyłączyłoby przerywanie przełącznika i ponownie ustawi timer na 950us, tak aby przerywanie timera ponownie włączyło przerywanie przełącznika. Czasami takie podejście może być przydatne, ale oprogramowanie jest o wiele bardziej skomplikowane niż proste / align = "left" / Gdy podejście oparte na zegarze będzie wystarczające, często jest to preferowane.

W systemach, które używają wielozadaniowego systemu operacyjnego zamiast bezpośrednich przerwań, stosuje się wiele tych samych zasad. Okresowe ankiety We/Wy tracą trochę czasu procesora w porównaniu z kodem, który system operacyjny nie uruchomi do czasu wystąpienia pewnych zdarzeń, ale w wielu przypadkach zarówno czas reakcji na zdarzenie, jak i ilość czasu zmarnowanego, gdy żadne zdarzenie nie wystąpi, będą akceptowane podczas korzystania z okresowego sondowania. Rzeczywiście, w niektórych buforowane sytuacje We/Wy, okresowe ankiety mogą okazać się dość skuteczne. Na przykład, załóżmy, że odbieramy dużą ilość danych ze zdalnej maszyny przez port szeregowy, co najwyżej 11 520 bajtów będzie przybywać na sekundę, urządzenie wyśle do 2k danych przed ostatnim potwierdzonym pakietem, a port szeregowy ma bufor wejściowy 4K. Chociaż można przetwarzać dane za pomocą zdarzenia "data received", równie efektywne może być sprawdzenie portu 100x / sekundę i przetworzenie wszystkich pakietów otrzymany do tego momentu. Takie ankiety byłyby stratą czasu, gdy zdalne urządzenie nie wysyłało danych, ale jeśli spodziewano się, że dane przychodzące będą bardziej wydajne, może być bardziej wydajne przetwarzanie ich w kawałkach około 1,15 K niż przetwarzanie każdego małego kawałka przychodzących danych, gdy tylko pojawią się.