.push() терпит неудачу или ждет, пока заблокирован в этом примере кода?

Question

Я хотел бы знать об этой странице https://github.com/zaphoyd/websocketpp/blob/experimental/examples/broadcast_server/broadcast_server.cpp написанной моим героем C++ zaphoyd прежде чем я начал свое приключение C++ websocket. Тонны уроков там.

Если я читаю это правильно (это натянуто), похоже, что соединения и посылки сообщений и поступления обрабатываются в одном потоке (не могу дождаться, пока он "многопоточный", или как он там называется, так как он говорит в этом базовом примере http://www.zaphoyd.com/websocketpp/manual/common-patterns/server-initiated-messages который WebSocket++ handlers block core networking functions. While this program is running its send loop in on_message, no new connections are being processed and no new messages are being received.) и отдельная тема boost::thread(bind(&broadcast_server::process_messages,&server)); настроен на фактическую обработку сообщений, в то время как основной поток websocket++ просто добавляет в очередь необходимую информацию.

Пожалуйста, проясните мою нехватку знаний: .push() сбой, если это происходит в то же время, что и этот раздел кода в ссылке

while(m_actions.empty()) {
    m_action_cond.wait(lock);
}

action a = m_actions.front();
m_actions.pop();

lock.unlock();

или делает .push() просто подождать, пока замок не будет снят?

Answer 1

std::queue<T> ничего не знает о потоках самостоятельно; однако в связанном коде все вызовы push обернуты следующим образом:

    boost::unique_lock<boost::mutex> lock(m_action_lock);
    //std::cout << "on_open" << std::endl;
    m_actions.push(action(SUBSCRIBE,hdl));
    lock.unlock();
    m_action_cond.notify_one();

Конструктор lock объект выше внутренних звонков m_action_lock.lock() который блокирует, пока замок не будет снят.

Обратите внимание, что m_action_cond.wait(lock)в коде, который вы вставили в свой вопрос, разблокирует блокировку во время ожидания условия и снова получает блокировку после ее пробуждения (либо из-за сигнала из другого потока, либо, возможно, из-за случайных действий), поэтому она не предотвратить производителя (тот, кто делает push) поток от получения блокировки во время ожидания: это только между пробуждением и вызовом lock.unlock() эта блокировка происходит.