Является ли DateTime.Now функцией привязки ввода-вывода?

Ответ 1

Вы глубоко в недокументированной территории с этим вопросом. Время предоставляется ядром: основной вызов API-интерфейса - NtQuerySystemTime(). Это действительно возится со всеми версиями Windows - Windows 8 особенно сильно изменила базовую реализацию с видимыми побочными эффектами.

Это связано с I/O по характеру: время поддерживается RTC (часы реального времени), которое раньше было выделенным чипом, но в настоящее время интегрировано в чипсет. Но есть очень веские доказательства того, что на практике это не связано с I/O. Синхронизация времени с тактовым прерыванием настолько велик, что обработчик прерываний считывает RTC, и вы получаете копию значения. Что-то, что вы можете видеть, когда вы возитесь с timeBeginPeriod().

И вы можете видеть, когда вы просматриваете его, что требуется только 7 наносекунд в Windows 10 - слишком быстро, чтобы быть привязанным к I/O.

Ответ 2

Кажется, вы обеспокоены блокировкой. Есть два случая, когда вы хотели бы этого избежать.

• В пользовательском интерфейсе это касается задержки. Неважно, что вы делаете (IO или CPU), это не займет много времени. В противном случае он замораживает поток пользовательского интерфейса. UtcNow очень быстрый, так что это не проблема.
• Иногда неблокирующий IO используется как способ масштабирования пропускной способности при добавлении большего количества нагрузки. Здесь единственная причина - сохранить потоки, потому что каждый поток потребляет много ресурсов. Поскольку нет асинхронного способа вызова UtcNow, вопрос является спорным. Вам просто нужно называть это как есть.

Поскольку время в Windows обычно достигает 60 Гц, я бы предположил, что вызов UtcNow считывается из переменной в памяти, которая записывается на 60 Гц. Это означает, что ЦП связан. Но это не имеет значения в любом случае.

Ответ 3

.NET использует API. MSDN говорит об API:

https://msdn.microsoft.com/de-de/library/windows/desktop/ms724961(v=vs.85).aspx

Когда система сначала запускается, она устанавливает системное время на значение, основанное на часах реального времени компьютера, а затем регулярно обновляет время [...] GetSystemTime копирует время в SYSTEMTIME [...]

Я не нашел надежных источников для резервного копирования своих утверждений о том, что он сохраняется как структура SYSTEMTIME, обновляется в нем и просто копируется в буфер приема GetSystemTime при вызове. Самая маленькая логическая единица - 100 нс из системного вызова NtQuerySystemTime, но мы заканчиваем с 1 миллисекундой в объекте CLR DateTime. Разрешение не всегда одно и то же.

Мы могли бы понять это для Mono в Linux, но вряд ли для Windows, учитывая, что сам код API не является общедоступным. Итак, это предположение: Текущее время является переменной в адресном пространстве ядра. Он будет обновляться ОС (часто с помощью прерывания таймера системного таймера, реже, может быть, из сетевого источника - в документации упоминается, что вызывающие абоненты не могут полагаться на монотонное поведение, поскольку сетевая синхронизация может корректировать текущее время назад). ОС будет синхронизировать доступ для предотвращения одновременной записи, но в противном случае это не будет дорогостоящей операцией ввода-вывода.

На последних компьютерах интервал таймера больше не фиксируется и может контролироваться BIOS и ОС. Приложения могут даже запрашивать более низкие или более высокие тактовые частоты: https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted