Udostępnij przez

Environment.TickCount został dostosowany do zachowania czasów wyjścia w systemie Windows

W systemie Windows Environment.TickCount i Environment.TickCount64 zostały zaktualizowane, aby były zgodne z zachowaniem widocznym w podstawowych interfejsach API oczekiwania dla systemu operacyjnego. Nie obejmują już czasu uśpienia ani hibernacji jako części mierzonego czasu. Ta zmiana sprawia również, że zachowanie systemu Windows jest spójne z zachowaniem widocznym na innych platformach i zapewnia, że jest aktualizowany z taką samą częstotliwością jak bazowy czasomierz przerwania dla systemu. Ta zmiana umożliwia większą szybkość reakcji w aplikacjach, które zdecydowały się na aktualizacje o wyższej częstotliwości.

Wersja wprowadzona

.NET 11 (wersja zapoznawcza 1)

Poprzednie zachowanie

Wcześniej w systemie Windows Environment.TickCount64 zwrócił wynik interfejsu API Win32 GetTickCount64, który został zaktualizowany z częstotliwością 10–16 ms (zazwyczaj 15,5 ms) i obejmował czas, w którym system przebywał w stanie uśpienia, hibernacji lub innych stanach niskiego zużycia energii.

Na innych platformach (takich jak Linux i macOS) Environment.TickCount64 aktualizowano z taką samą częstotliwością, co podstawowy zegar przerwań dla systemu, i obejmował tylko czas, kiedy system był uznawany za "obudzony".

Na wszystkich platformach Environment.TickCount zwrócił skrócony wynik Environment.TickCount64 i wykazywał identyczne zachowanie, ale dochodziło do przepełnienia mniej więcej co 49 dni.

Nowe zachowanie

W systemie Windows Environment.TickCount64 teraz zwraca wynik funkcji API Win32 QueryUnbiasedInterruptTime. Ta zmiana sprawia, że interfejs API platformy .NET jest zgodny z zachowaniem stosowanym w podstawowych interfejsach API oczekiwania w systemie operacyjnym. Nie obejmuje on już czasu nieaktywnego i aktualizuje się z taką samą częstotliwością jak bazowy czasomierz przerwań systemu.

Na innych platformach Environment.TickCount64 zachowuje swoje zachowanie, co jest zgodne z nowym zachowaniem w systemie Windows.

Na wszystkich platformach Environment.TickCount zachowuje swoją implementację i odzwierciedla zachowanie elementu Environment.TickCount64.

Typ zmiany przełamującej

Ta zmiana jest zmianą behawioralną.

Przyczyna zmiany

Windows wprowadził podobną zmianę wpływającą na zgodność działania w Windows 8 i Windows Server 2012 oraz nowszych wersjach, tak aby interfejsy API akceptujące limit czasu (na przykład SleepEx i WaitForMultipleObjectsEx) nie uwzględniały już czasu, gdy system nie jest w stanie aktywnym. Spowodowało to niespójność z platformą .NET, ponieważ takie interfejsy API oczekiwania są często używane w połączeniu z mechanizmem Environment.TickCount64, co prowadzi do trudnych do zdiagnozowania błędów, takich jak nieoczekiwane uruchomienie się liczników czasu.

Ponadto podstawowy interfejs API, który został zastosowany, GetTickCount64, był mniej precyzyjny i aktualizowany tylko przy stałej rozdzielczości. Ta rozdzielczość nie została skorygowana, jeśli bazowy czasomierz przerwania dla systemu operacyjnego zmienił częstotliwość, co może prowadzić do wykonania dodatkowej pracy w przypadku aplikacji, które zdecydowały się uruchamiać z wyższym priorytetem. Zachowanie było również niezgodne z zachowaniem widocznym na innych platformach, takich jak macOS i Linux.

Zmiana zapewnia spójność z bazowym systemem operacyjnym i na różnych platformach. Może to również prowadzić do większej reakcji w aplikacjach, które zdecydowały się na częstsze aktualizacje.

O ile nie zdecydujesz się na czas przerwania o wyższej częstotliwości, większość kodu nie powinna mieć żadnych zmian w zachowaniu. Aplikacje będą nadal widzieć aktualizacje z taką samą częstotliwością jak poprzednio. Jeśli jednak częstotliwość aktualizacji jest odpowiednia, upewnij się, że limity czasu są przekazywane we właściwej wartości spełniającej oczekiwania kodu lub upewnij się, że aplikacja nie decyduje się na zbyt wysoką częstotliwość aktualizacji. (Można to zrobić tylko za pośrednictwem interfejsów API P/Invoke).

Niektóre timery mogą nie uruchamiać się natychmiast po wybudzeniu maszyny ze stanu uśpienia lub niskiego zużycia energii. Jeśli taki czas jest odpowiedni, użyj interfejsów API, takich jak DateTime.UtcNow , aby zapewnić, że taki czas może być zawsze uwzględniony. Taki kod może być musiał uwzględnić potencjalne korekty zegara.

Kod, na który wpływa ta zmiana w systemie Windows, prawdopodobnie jest również dotknięty tym samym scenariuszem na innych platformach, takich jak Linux i macOS.

Interfejsy API, których dotyczy problem

  • Last updated on