С++ 11 Поведение ожидания потока: std::this_thread::yield() против std::this_thread::sleep_for( std::chrono::milliseconds(1))

Стандарт здесь несколько нечеток, так как конкретная реализация будет в значительной степени зависеть от возможностей планирования базовой операционной системы.

При этом вы можете смело предположить несколько вещей в любой современной ОС:

• yield откажется от текущего кванта времени и повторно вставит поток в очередь планирования. Количество времени, которое истекает до повторного выполнения потока, обычно полностью зависит от планировщика. Обратите внимание, что в Стандарте доходность рассматривается как возможность изменить график. Таким образом, реализация может полностью вернуться из yield немедленно, если пожелает. Выход никогда не помечает поток как неактивный, поэтому поток, работающий на доходе, всегда будет производить 100% нагрузку на одно ядро. Если никакие другие потоки не готовы, вы, вероятно, потеряете не более остатка текущего кванта времени, прежде чем вы снова будете запланированы.
• sleep_* заблокирует поток как минимум на запрошенное время. Реализация может превратить sleep_for(0) в yield. С другой стороны, sleep_for(1) приостановит вашу нить. Вместо того, чтобы вернуться в очередь планирования, поток сначала переходит в другую очередь спящих потоков. Только по истечении запрошенного времени планировщик рассмотрит возможность повторной вставки потока в очередь планирования. Нагрузка, производимая небольшим сном, все равно будет очень высокой. Если запрошенное время ожидания меньше, чем системный квант времени, вы можете ожидать, что поток пропустит только один квант времени (то есть один выход, чтобы освободить активный квант времени, а затем пропустить другой), что все равно приведет к загрузке ЦП. близко или даже равно 100% на одном ядре.

Несколько слов о том, что лучше для спин-блокировки. Спин-блокировка — это предпочтительный инструмент, когда ожидается, что конкуренция за блокировку будет минимальной или вообще отсутствовать. Если в подавляющем большинстве случаев вы ожидаете, что блокировка будет доступна, спин-блокировки — дешевое и ценное решение. Однако, как только возникнут разногласия, спин-блокировки будут стоить вам денег. Если вы беспокоитесь о том, что лучше — yield или sleep, спин-блокировки — неподходящий инструмент для этой работы. Вместо этого вы должны использовать мьютекс.

Для спин-блокировки случай, когда вам действительно нужно дождаться блокировки, следует считать исключительным. Поэтому совершенно нормально просто уступить здесь - это ясно выражает намерение, и трата процессорного времени никогда не должна вызывать беспокойства.

Я только что провел тест с Visual Studio 2013 на Windows 7, Intel i7 2,8 ГГц, оптимизация режима выпуска по умолчанию.

sleep_for(nonzero) засыпает минимум на одну миллисекунду и не требует ресурсов ЦП в цикле, например:

for (int k = 0; k < 1000; ++k)
    std::this_thread::sleep_for(std::chrono::nanoseconds(1));

Этот цикл из 1000 снов занимает около 1 секунды, если вы используете 1 наносекунду, 1 микросекунду или 1 миллисекунду. С другой стороны, yield() занимает около 0,25 микросекунд каждый, но задействует ЦП на 100% для потока:

for (int k = 0; k < 4,000,000; ++k) (commas added for clarity)
    std::this_thread::yield();

std::this_thread::sleep_for((std::chrono::nanoseconds(0)) кажется примерно таким же, как yield() (тест здесь не показан).

Для сравнения, блокировка atomic_flag для спин-блокировки занимает около 5 наносекунд. Этот цикл составляет 1 секунду:

std::atomic_flag f = ATOMIC_FLAG_INIT;
for (int k = 0; k < 200,000,000; ++k)
    f.test_and_set();

Кроме того, мьютекс занимает около 50 наносекунд, 1 секунду для этого цикла:

for (int k = 0; k < 20,000,000; ++k)
    std::lock_guard<std::mutex> lock(g_mutex);

Основываясь на этом, я, вероятно, без колебаний поместил бы yield в спин-блокировку, но почти наверняка не стал бы использовать sleep_for. Если вы считаете, что ваши блокировки будут много вращаться, и беспокоитесь о потреблении ресурсов процессора, я бы переключился на std::mutex, если это целесообразно в вашем приложении. Будем надеяться, что дни действительно плохой производительности std::mutex в Windows остались позади.

если вас интересует загрузка процессора при использовании yield - это очень плохо, за исключением одного случая - (работает только ваше приложение, и вы в курсе, что оно в основном съест все ваши ресурсы)

вот еще объяснение:

• запуск yield в цикле гарантирует, что процессор прекратит выполнение потока, но если система попытается вернуться к потоку, она просто повторит операцию yield. Это может заставить поток использовать полную 100% загрузку ядра процессора.
• запуск sleep() или sleep_for() также является ошибкой, это заблокирует выполнение потока, но у вас будет что-то вроде времени ожидания на процессоре. Не ошибитесь, это рабочий процессор, но с самым низким приоритетом. Хотя каким-то образом работая над простыми примерами использования (полностью загруженный процессор в sleep() вдвое хуже, чем полностью загруженный рабочий процессор), если вы хотите обеспечить ответственность приложения, вам нужно что-то вроде третьего примера:

• комбинируя! :

  std::chrono::milliseconds duration(1);
  while (true)
     {
        if(!mutex.try_lock())
        {
             std::this_thread::yield();
             std::this_thread::sleep_for(duration);
             continue;
        }
        return;
     }
  

что-то вроде этого гарантирует, что процессор будет работать так же быстро, как эта операция будет выполнена, а также sleep_for() гарантирует, что процессор будет ждать некоторое время, прежде чем даже пытаться выполнить следующую итерацию. Это время, конечно, может быть динамически (или статически) настроено в соответствии с вашими потребностями.

ваше здоровье :)

То, что вы хотите, вероятно, является переменной условия. Переменная условия с функцией условного пробуждения обычно реализуется так же, как то, что вы пишете, со сном или выходом внутри цикла, ожидающим выполнения условия.

Ваш код будет выглядеть так:

std::unique_lock<std::mutex> lck(mtx)
while(!bSomeCondition) {
    cv.wait(lck);
}

Or

std::unique_lock<std::mutex> lck(mtx)
cv.wait(lck, [bSomeCondition](){ return !bSomeCondition; })

Все, что вам нужно сделать, это уведомить переменную условия в другом потоке, когда данные будут готовы. Однако вы не можете избежать блокировки, если хотите использовать условную переменную.