Betrachten Sie das folgende Beispiel.

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() "weiß, dassf() wartet in dem Szenario, das ich diskutieren möchte. Gemäß cppreference.com es besteht keine Notwendigkeit fürg(), um den Mutex zu sperren, bevor Sie @ aufrufnotify_one. Jetzt in der mit "1" gekennzeichneten Zeilecv gibt den Mutex frei und sperrt ihn erneut, sobald die Benachrichtigung gesendet wurde. Der Zerstörer vonlock gibt es danach sofort wieder frei. Dies scheint überflüssig zu sein, zumal das Verriegeln teuer ist. (Ich weiß, dass in bestimmten Szenarien der Mutex gesperrt werden muss. Dies ist hier jedoch nicht der Fall.)

Warum tutcondition_variable habe keine Funktion "wait_nolock "das den Mutex nicht wieder sperrt, sobald die Benachrichtigung eintrifft. Wenn die Antwort lautet, dass Pthreads diese Funktionalität nicht bieten: Warum können Pthreads nicht für die Bereitstellung erweitert werden? Gibt es eine Alternative, um das gewünschte Verhalten zu realisieren?