Рассмотрим следующий пример.

std::mutex mtx;
std::condition_variable cv;

void f()
{
  {
    std::unique_lock<std::mutex>  lock( mtx );
    cv.wait( lock );  // 1
  }
  std::cout << "f()\n";
}

void g()
{
  std::this_thread::sleep_for( 1s );
  cv.notify_one();
}

int main()
{
  std::thread  t1{ f };
  std::thread  t2{ g };
  t2.join();
  t1.join();
}

g() "знает", чтоf() ждет в сценарии, который я хотел бы обсудить. В соответствии сcppreference.com нет необходимости вg() заблокировать мьютекс перед вызовомnotify_one, Теперь в строке отмечено «1»cv освободит мьютекс и заблокирует его после отправки уведомления. Деструкторlock выпускает это снова немедленно после этого. Это кажется излишним, тем более что блокировка стоит дорого. (Я знаю, что в определенных сценариях мьютекс должен быть заблокирован. Но это не тот случай.)

Почемуcondition_variable не имеет функции "wait_nolock"который не блокирует мьютекс после получения уведомления. Если ответ таков, что pthreads не предоставляют такую ​​функциональность: почему нельзя расширить pthreads для его предоставления? Есть ли альтернатива для реализации желаемого поведения?