Дождитесь завершения отсоединенного потока в C++

как я могу дождаться завершения отсоединенного потока на C++?

меня не волнует статус выхода, я просто хочу знать, закончился ли поток.

Я пытаюсь предоставить синхронную оболочку вокруг асинхронного инструмента thirdarty. Проблема заключается в странном состоянии гонки аварии с участием обратного вызова. Прогрессия:

1. Я звоню третьей стороне и регистрирую обратный вызов
2. когда thirdparty заканчивает, оно уведомляет меня с помощью обратного вызова - в отдельном потоке у меня нет реального контроля.
3. Я хочу, чтобы поток из (1) ждал, пока не будет вызван (2).

Я хочу, чтобы обернуть это в механизм, который обеспечивает блокировку вызова. До сих пор я:

class Wait {
  public:
  void callback() {
    pthread_mutex_lock(&m_mutex);
    m_done = true;
    pthread_cond_broadcast(&m_cond);
    pthread_mutex_unlock(&m_mutex);
  }

  void wait() {
    pthread_mutex_lock(&m_mutex);
    while (!m_done) {
      pthread_cond_wait(&m_cond, &m_mutex);
    }
    pthread_mutex_unlock(&m_mutex);
  }

  private:
  pthread_mutex_t m_mutex;
  pthread_cond_t  m_cond;
  bool            m_done;
};

// elsewhere...
Wait waiter;
thirdparty_utility(&waiter);
waiter.wait();

насколько я могу судить, это должно сработать, и обычно это так, но иногда он падает. Насколько я могу определить из corefile, моя догадка о проблеме такова:

1. когда обратный вызов передает конец m_done, поток ожидания просыпается
2. поток ожидания теперь сделан здесь, и ожидание уничтожено. Все члены Wait уничтожены, включая мьютекс и cond.
3. поток обратного вызова пытается продолжить с точки трансляции, но теперь использует освобожденную память, что приводит к повреждению памяти.
4. когда поток обратного вызова пытается вернуться (выше уровня моего плохого метода обратного вызова), программа сбои (обычно с SIGSEGV, но я видел SIGILL пару раз).

Я пробовал много разных механизмов, чтобы попытаться исправить это, но ни один из них не решит проблему. Я все еще вижу случайные аварии.

редактировать: Подробнее:

Это часть многопоточного приложения, поэтому создание статического ожидания нецелесообразно.

я запустил тест, создав ожидание в куче и намеренно утечка памяти (т. е. объекты ожидания никогда не освобождаются), и это не привело к сбоям. Поэтому я уверен, что проблема в том, чтобы ждать слишком рано.

Я также пробовал тест с sleep(5) после разблокировки в wait, и это также не привело к сбоям. Я ненавижу полагаться на таких клуджей.

редактировать: детали ThirdParty:

сначала я не думал, что это важно, но чем больше я думаю об этом, тем больше я думаю, что это реально проблема:

материал thirdparty, который я упомянул, и почему у меня нет контроля над потоком: это использование CORBA.

таким образом, возможно, что Корба держит ссылку на мой объект дольше, чем предполагалось.