Если вы просто тестируете простое изменение состояния (когда выходить), достаточно условной переменной. Просто убедитесь, что вы найдете хороший пример WinAPI для подражания: вам почти наверняка нужно многократно проверять состояние (в отличие от того, что ваша интуиция может вам сказать).
Если вы намерены делиться задачами /Для событий между потоками рекомендуется использовать шаблон производитель-потребитель , основанный на очереди с мьютексом и условной переменной.Типичный пример: у вас есть один поток производителя , который создает задания, помещаемые в очередь (например, запись данных в другой файл для каждой задачи).Тогда у вас может быть несколько пользовательских потоков , которые будут удалять задачу из очереди и воздействовать на них.Для связи между потоками вы можете иметь условную переменную , которая будет сигнализировать потокам потребителя, что очередь мьютекса может быть пустой .(Ознакомьтесь с переменными условия, чтобы понять, почему я говорю «может» здесь).
По мере того, как вы будете все больше и больше программировать потоки, вы будете искать возможности, когда мьютексы не нужны.Например, если у меня есть тонна данных только для чтения на диске, и я хочу, чтобы ваши потоки рассчитывали по этим данным, вы можете прочитать данные , прежде чем создавать свои потоки .Все ваши потоки будут иметь доступ к этим данным без использования блокировок, если они ведут себя и не записывают данные.Вы обнаружите, что вы реализуете множество шаблонов потоков, используя только мьютексы и условные переменные (отчасти это объясняется тем, что библиотека потоков POSIX настолько мала).
Последнее замечание: это немного выходит за рамки вашего вопроса, но вы также почувствуете, сколько потоков вам действительно нужно порождать.Переключение контекста между потоками относительно дешево, но стоимость определенно не равна нулю.Это означает, что при порождении большего количества потоков существует точка уменьшения отдачи.Подумайте об этом с точки зрения ОС: алгоритм должен тратить циклы, чтобы решить, когда переключать контекст в дополнение к фактическому переключению.Эта стоимость не равна нулю.Таким образом, другой тип оптимизации, который вы найдете при выполнении большего количества потоковых программ, - это когда нужно выполнять в потоке как можно больше работы, не дожидаясь, пока другой поток выполнит эту работу.Конечно, вы должны найти баланс между чистотой вашего дизайна и оптимизацией по скорости.Об этом нужно подумать при разработке приложения.