• naurM
    link
    fedilink
    Polski
    arrow-up
    1
    ·
    6 months ago

    Dla mnie timer ma sens chyba tylko w przypadku istnienia jakiejś pętli zdarzeń.
    Jasne, można kombinować z wątkami jak Cherno, ale w praktyce takie podejście ma sporo wad (o których zresztą wspomniał).

    Biblioteka standardowa oczywiście nie zawiera takich mechanizmów, ale gotowych bibliotek jest mnóstwo (chociażby Boost.Asio).

    • サぺルOP
      link
      fedilink
      Polski
      arrow-up
      1
      ·
      6 months ago

      Dla mnie blokada programu na określony czas jest najmniej praktyczna. Była praktyczna w czasach jedno-rdzeniowych, kiedy pętla jednego wątku mogła wysycić czas procesora.

      Wątki odliczające czas są używane chyba często w gamedev. Twierdzą, że są bardziej precyzyjne. Nie wiem jak się używa tego sprzętowego timera do multimediów. Jeśli wiesz to napisz. Czy abstrakcje systemu to zniszczyły?

      Pętla zdarzeń to określone zastosowania i nie wszędzie pasują.

      Coś co zwraca informację o tym czy czas już upłynął jest dla mnie najbardziej wszechstronne. Sam napisałem coś takiego kiedyś dla Arduino. Interakcja ze społecznością nie była zbyt fajna. Nie udoskonalałem tego dzięki nim, tylko dzięki doświadczeniu. Oni tylko wytykali ogólne braki, które nie były dla mnie problemem.

      • naurM
        link
        fedilink
        Polski
        arrow-up
        1
        ·
        6 months ago

        Przeniesienie zadań wymagających precyzyjnego pomiaru czasu na odrębny wątek może mieć tę zaletę, że da się wtedy ustawić priorytet w schedulerze.
        Wadą może być to, że samo przekazanie zdarzenia między wątkami może generować opóźnienia.

        “Za moich czasów”™ najbardziej precyzyjnym sposobem pomiaru czasu na Windows było QueryPerformanceCounter, które może być oparte na liczniku RDTSCP procesora.

        Może jest obecnie dostępny jakiś inny mechanizm, ale chyba nie da się znacząco poprawić tego API.