Вы можете удалить его сразу.
Цитата из стандарта C ++:
~ condition_variable();
Требуется : должно бытьни одна нить не заблокирована на *this
.[Примечание: то есть все темы должны быть уведомлены;впоследствии они могут заблокировать блокировку, указанную в wait
.Это ослабляет обычные правила, которые требовали бы, чтобы все вызовы wait
происходили до уничтожения. Перед уничтожением должно происходить только уведомление о разблокировке wait
.
В основном wait
функции необходимы для атомарной блокировки и ожидания:
Выполнение notify_one
и notify_all
должно быть атомарным.Выполнение wait
, wait_for
и wait_until
должно выполняться в трех атомарных частях:
- освобождение мьютекса и вход в состояние ожидания;
- разблокировка
wait
;и - повторное получение блокировки.
Как только notify
пробуждает поток, его следует считать "разблокированным" и бороться с мьютексом.
Существуют аналогичные гарантии в отношении std::mutex
: потоки не обязаны выходить из unlock
до уничтожения мьютекса.
Цитата из стандарта C ++:
Реализацияобеспечивает операции lock
и unlock
, как описано ниже.В целях определения существования гонки данных они ведут себя как атомарные операции.Операции lock
и unlock
на одном мьютексе должны выполняться в едином общем порядке.
Позже:
Примечание: после того, как поток A имеетвызываемый unlock()
, освобождая мьютекс, другой поток B может заблокировать тот же мьютекс, заметить, что он больше не используется, разблокировать его и уничтожить его до того, как поток A, кажется, вернулся из своегоunlock
call .
Такие гарантии необходимы, чтобы избежать таких проблем, как this , когда мьютекс внутри объекта используется для защиты счетчика ссылок на объекты.
Обратите внимание, что это не гарантирует, что ваша реализация не содержит ошибок в этом отношении.В прошлом у glibc было несколько ошибок, связанных с уничтожением объектов синхронизации, в частности pthread_mutex_unlock
имел доступ к мьютексу перед возвратом .