Hängt davon ab, was die Senken tun (und andere Quellen).
In Ihrem zweiten Codebeispiel ist es möglich, dass zwischen dem Entsperren und dem Senden mehrere andere Threads kommen und eine Kombination von Dingen ausführen, was die Bedingung wieder falsch macht. Sie werden dann sinnlos senden. Und Sie werden nicht unbedingt die gleichen Kellner haben wie bei der Änderung der Bedingung, die sich auf Ihr Design auswirken könnte oder nicht.
Ein anständiges Waschbecken sollte sich nicht darum kümmern, ob es aufgeweckt wird und der Zustand falsch ist, besonders wenn Sie Broadcast benutzen. Solange jede Änderung der Bedingung auf "wahr" schließlich von einer Übertragung gefolgt wird, bin ich mir ziemlich sicher, dass Sie mit entsprechend geschriebenen Senken eine Zustandsvariable willy-nilly mit oder ohne Sperre senden können.
Ich denke also nicht, dass es wirklich wichtig ist, aber persönlich würde ich mit gehaltener Sperre senden, um nicht zu befürchten. "Atomic change-and-signal" könnte das Zustandsdiagramm auf Ihrem Whiteboard im Vergleich zu "change ... einige Zeit später, signal" vereinfachen.
Beide sind richtig (im Gegensatz zum Warten ohne Mutex, was nicht erlaubt ist), aber ich denke nicht, dass es zu schwierig wäre, Anwendungen zu finden, die im zweiten Fall schief gehen können, das würde nicht gehen falsch in der ersten. Sie müssten wahrscheinlich einige Kellner mit einbeziehen, die etwas Ungewöhnliches machen.
Die Spezifikation sagt ziemlich kryptisch: "Wenn vorhersehbares Planungsverhalten erforderlich ist, dann sollte der Mutex durch den Thread gesperrt werden, der pthread_cond_broadcast () oder pthread_cond_signal () aufruft."