Partager via

Environment.TickCount a été rendu cohérent avec le comportement du délai d'attente Windows

Sur Windows, Environment.TickCount et Environment.TickCount64 ont été mis à jour pour être cohérents avec le comportement affiché dans les API d’attente sous-jacentes pour le système d’exploitation. Ils n’incluent plus le temps de veille ou de veille prolongée dans le cadre du temps écoulé mesuré. Cette modification rend également le comportement Windows cohérent avec le comportement affiché sur d’autres plateformes et garantit qu’il est mis à jour à la même fréquence que le minuteur d’interruption sous-jacent pour le système. Cette modification permet une réactivité plus élevée dans les applications qui ont choisi d’effectuer des mises à jour à fréquence plus élevée.

Version introduite

.NET 11 Preview 1

Comportement précédent

Auparavant, sur Windows, Environment.TickCount64 renvoyait le résultat de l’API Win32 GetTickCount64 , mise à jour à une cadence fixe de 10 à 16 ms (généralement 15,5 ms) et incluait le temps passé par le système en veille, en veille prolongée ou à d’autres états à faible puissance.

Sur d’autres plateformes (telles que Linux et macOS), Environment.TickCount64 mises à jour à la même fréquence que le minuteur d’interruption sous-jacent pour le système et incluaient uniquement le moment où le système était considéré comme « éveillé ».

Sur toutes les plateformes, Environment.TickCount a retourné le résultat tronqué de Environment.TickCount64 et a présenté un comportement identique, mais était soumis à un dépassement de capacité environ tous les 49 jours.

Nouveau comportement

Sur Windows, Environment.TickCount64 retourne maintenant le résultat de l’API Win32 QueryUnbiasedInterruptTime . Cette modification aligne l'API .NET sur le comportement utilisé dans les APIs d’attente sous-jacentes du système d’exploitation. Il n’inclut plus le temps non éveillé et se met à jour à la même fréquence que le minuteur d’interruption sous-jacent pour le système.

Sur d’autres plateformes, Environment.TickCount64 conserve son comportement, qui est cohérent avec le nouveau comportement sur Windows.

Sur toutes les plateformes, Environment.TickCount conserve son implémentation et met en miroir le comportement de Environment.TickCount64.

Type de changement cassant

Ce changement est un changement de comportement.

Raison de la modification

Windows a introduit un changement de comportement similaire perturbant dans Windows 8 ainsi que Windows Server 2012 et les versions ultérieures, de manière à ce que les API qui acceptent un délai d'expiration (comme SleepEx et WaitForMultipleObjectsEx) ne prennent plus en compte le temps non actif. Cela a provoqué une incohérence avec .NET, car ces API d’attente sont fréquemment utilisées conjointement avec Environment.TickCount64, ce qui entraîne un diagnostic difficile des bogues tels que les minuteurs qui se déclenchent de manière inattendue.

En outre, l’API sous-jacente utilisée, GetTickCount64, était moins précise et uniquement mise à jour à une résolution fixe. Cette résolution n’a pas été ajustée si le minuteur d’interruption sous-jacent pour le système d’exploitation avait sa fréquence modifiée, ce qui pourrait entraîner des tâches supplémentaires effectuées pour les applications qui avaient choisi d’exécuter à une priorité plus élevée. Le comportement était également incohérent avec le comportement vu sur d’autres plateformes telles que macOS et Linux.

La modification garantit la cohérence avec le système d’exploitation sous-jacent et entre les plateformes. Elle peut également entraîner une réactivité plus élevée dans les applications qui ont choisi des mises à jour plus fréquentes.

Sauf si vous avez choisi des temps d’interruption de fréquence plus élevés, la plupart du code ne doit pas subir de changement de comportement. Les applications continueront à voir les mises à jour à la même fréquence qu’auparavant. Toutefois, si la fréquence de mise à jour est pertinente, assurez-vous que vos délais d’attente passent dans une valeur correcte qui répond aux attentes de votre code, ou assurez-vous que l’application ne choisit pas une fréquence de mise à jour trop élevée. (Cette opération peut uniquement être effectuée via des API P/Invoke aujourd’hui.)

Certains codes peuvent voir que les minuteurs ne se déclenchent plus immédiatement après qu’une machine se réveille à partir d’un état de veille ou de faible puissance. Si ce moment est pertinent, utilisez des API telles que DateTime.UtcNow pour vous assurer que ce temps peut toujours être inclus. Ce code peut avoir à tenir compte des ajustements potentiels de l’horloge.

Le code affecté par cette modification sur Windows est probablement déjà affecté par le même scénario sur d’autres plateformes telles que Linux et macOS.

API affectées

  • Last updated on