Альтернатива SpinWait.SpinUntil

Question

Мы используем Задачу в нашем приложении. В одном классе мы хотим запустить обновление, которое выполняется для параллельной задачи. Звонок выглядит так:

            Maintenance.RecievedMessage += new NotificationHandler(Maintenance_RecievedMessage);
            Maintenance.checkLastXML = false;
            Maintenance.NeedToUpdateFromCarrier(userId);

        SpinWait.SpinUntil(() => isCompleted == true);
        return true;

Итак, мы подключаем событие, которое запускается, когда Maintenance.NeedToUpdateFromCarrier (userId); Метод выполнен бегом. Полный метод выглядит так:

 private void Maintenance_RecievedMessage(IsCompleted changeargs)
    {
        isCompleted = true;
    }

Итак, мы ждем метод NeedToUpdateFromCarrier, как только он будет завершен, он инициирует событие, которое было выполнено, и мы перехватываем событие и устанавливаем для свойства isComplete значение true, и это происходит тогда, когда завершается окончательное SpinWait.SpinUntil, и мы продолжаем.

Поскольку SpinWait.SpinUntil очень тяжел для процессора, сейчас я ищу альтернативное решение этой проблемы.

Answer 1

Важно понимать, когда уместно ожидание вращения.Есть очень мало случаев, когда это так.Ожидание вращения оптимизирует переключение контекста потока.Всякий раз, когда вы чего-то ждете, вызов вроде WaitHandle.Wait () заблокирует поток и выдаст процессор.Операционная система выполняет переключение контекста потока, когда она находит другой поток для выполнения полезной работы.

Переключения контекста потока довольно дороги.Точного числа нет, потому что это зависит от того, где выполняется поток yield-to, есть дополнительные издержки, когда этот поток выполняется в другом процессе или в кольце защиты (драйверах).Это стоит от 2000 до 10000 циклов.

Это циклы процессора, которые мало что достигают.Только накладные расходы, которые не делают настоящую работу.Вы можете оптимизировать свой код многопоточности, если вы знаете , что для выполнения условия ожидания всегда требуется менее 20000 циклов.Простая задержка потока (вращение) обеспечит отсутствие необходимости в дорогостоящем переключении контекста.Это не обычный тип задержки, такой как Thread.Sleep (), который дает, это небольшой цикл, который сжигает 100% ядро.При добавлении нескольких смартов, например, вращение на машине с одним ядром никогда не будет работать нормально, поэтому оно все равно даст результат.

Очевидно, что это не будет работать хорошо, если условие ожидания последовательно занимает более 20 000 циклов.Теперь вы находитесь на другом конце мудрого выбора, вы do хотите уступить в этих случаях.Не только для того, чтобы избежать сжигания процессора, когда он ничего не выполняет, но особенно потому, что уступка делает его теперь более вероятным, что условие ожидания будет выполнено раньше.Потому что вы увеличиваете вероятность того, что поток, который задает условие ожидания, может получить достаточно циклов ЦП, чтобы завершить свою работу.

В вашем коде достаточно доказательств.Вы явно просите код сделать что-то перед вращением.И это требует обработчика событий, чтобы сигнализировать о завершении.Mucho код должен быть запущен.И наиболее убедительно, вы видите много сожженных процессоров.1% нагрузки в TaskMgr.exe составляет около 20 миллионов тактов процессора.

Вместо этого используйте ожидаемое событие, например AutoResetEvent.Обратите внимание, что требуется структурное изменение, isCompleted больше не может быть булом.Вы вызываете Set () в обработчике завершения, Wait (), чтобы заблокировать его.

Answer 2

Вы можете использовать ManualResetEventSlim :

var signal = new ManualResetEventSlim();

Maintenance.RecievedMessage += delegate { signal.Set(); };
Maintenance.checkLastXML = false;
Maintenance.NeedToUpdateFromCarrier(userId);

signal.Wait();
return true;