Как правильно использовать блокировки?

Question

[lightalex]

Доброго времени суток!
Пытаюсь использовать mutex для блокировки потока

std::mutex locker;
locker.lock();
// Здесь идёт работа с потоками в конце которой будет вызвано locker.unlock();
locker.lock();

Мне необходимо использовать блокировки для того чтобы убедиться что потоки закончили свою работу
Но при выполнении программа вываливается на втором locker.lock();
Как правильно воспользоваться блокировками в данном случае?
P.S. Задачу нужно решить именно блокировками mutex. Пример я написал очень условный, чтобы не нагружать вопрос лишним кодом

Answer 1

[lightalex]

Подведу итоги моего мучения с данной проблемой, если вдруг кто-то столкнется с той же проблемой
В одном потоке нельзя использовать locker.lock() два раза подряд, так как имеется защита от мертвых блокировок
Был использован следующий костыль:

std::mutex locker;
boost::thread t([&]() {
	locker.lock();
});
t.join();
...
locker.lock();

Comments

[devalone]

Что за бред? Зачем?

[lightalex]

devalone, почему сразу бред?
Просто костыль :)
Я использую класс, который вызывает несколько потоков, один в другом
И мне нужно дождаться пока все потоки совершат свою работу и только потом идти дальше по основной программе
Там класс https запроса
Код представляет из себя что-то типа этого:

std::string info = "Hello world!";
request->query("https://site.com/", [&]{
  std::cout << info;
});

И в результате info для callback'а становится недоступным, так как основной поток завершается и уничтожает все локальные переменные
Можно конечно передавать нужные переменные в функцию callback'а, но это слишком геморно так как я использую много локальных переменных (это я для примера всего одну переменную написал)
Так что легче просто удерживать основной поток, пока callback не завершит работу

[devalone]

lightalex, тебе нужно менять архитектуру, потому что это костыли какие-то.

И мне нужно дождаться пока все потоки совершат свою работу и только потом идти дальше по основной программе

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

[Александр Павлов]

lightalex, блокировки нужны для синхронизации доступа к данным. Если нужно дождаться завершения остальных потоков – используете цикл по массиву потоков и для каждого вызовите join.

[lightalex]

devalone, я не зря сказал что там несколько потоков, один в другом
Я знаю и про join, и про future&async
Просто задача очень специфичная и требует именно такой реализации класса
Тут идет ставка на скорость отправки запроса
И там довольно сложный класс этим занимается
Просто в данном куске кода я не совсем по назначению использую класс
Фишка в том что таких мест 2-3, где не обязательно использовать возможности класса
Но смысл ради эти 2-3 мест писать отдельный класс, когда данные куски кода вызываются крайне редко, а также там не требуется ни скорость, ни оптимизация? Бессмысленно, ведь можно костылить :)
+ мне было интересно выяснить что не так со вторым lock, что и определило создание вопроса на тостере
P.S. на всякий случай уточню что программа пишется для личного использования, так что можно и немного грязи в коде допустить

[lightalex]

Александр Павлов, join'ом не получится
Самый главный аргумент, что callback отправляется в отдельный поток, пока класс доделывает необходимые действия
К тому же за один request->query может создаться несколько вложенных друг в друга потоков. И при этом callback может вообще не вызваться напрямую из текущего потока, так как класс может отправить запрос в очередь и тогда им займется вообще другой поток, который работает совершено независимо
Короче говоря, не вариант
А на счет применения блокировок... Почему я не могу их применить в данном случае? Раз где-то написано "применяется для синхронизации доступа к данным", это ведь не значит что нельзя с помощью блокировок синхронизировать потоки? Или имеются какие-то серьезные аргументы против?
И кстати, я конечно не уверен, но вроде я все-таки пытаюсь как раз "синхронизировать доступ к данным". Даю потоку доступ к данным раньше, чем его получит оптимизатор памяти :)

[Александр Павлов]

lightalex, понял, в таком случае действительно вариантов не много.

Но разве этот костыль работает? Вы запускаете поток, который блокирует mutex. Сразу после ожидаете завершение потока и затем снова пытаетесь блокировать mutex, но уже в основном потоке. И в этом месте программа зависает, потому что mutex уже заблокирован и основной поток будет ждать его разблокировки. Каким образом вы освободите mutex в других потоках?

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

[devalone]

lightalex, повторюсь, проблема в архитектуре. Если нужна скорость - используй асинхронную библиотеку, их куча.

[lightalex]

Александр Павлов, я там три точки поставил
Подразумевается, что там будет произведен unlock
Полный код выглядит как-то так:

std::mutex locker;
boost::thread t([&]() {
  locker.lock();
});
t.join();

std::string info = "Hello world!";
request->query("https://site.com/", [&]{
  std::cout << info;
  locker.unlock();
});

locker.lock();

Основной поток будет существовать, пока callback не закончит свою работу. Конечно по хорошему нужно передавать переменные в callback, а не удерживать локальные переменные. Но в данном случае овчинка выделки не стоит :)

[lightalex]

devalone, ок, спасибо за ваше мнение, я его услышал
Просто как я уже говорил, в данном случае скорость достигается не асинхронностью
Не там время экономится
У класса свои методы, как работать быстрее
Как я уже говорил, я не совсем по назначению использую данный класс в данном месте, поэтому и приходится применять вот такие костыли
Когда я использую класс в нужном месте, нет смысла удерживать основной поток, так как он отправляет запрос, а дальше ему на него совершено наплевать. Задача основного потока просто вызывать метод

[devalone]

lightalex, я к тому, что больше аппаратного количества потоков всегда будет не эффективно, т.к. будет много времени тратиться на переключение контекста. Если всё-таки использовать потоки, то может быть стоит сделать, чтоб request->query возвращал future, их добавить в массив и ждать завершения всех запросов.

А вообще без знания конкретной задачи сложно что-либо советовать.

Answer 2

[Александр Таратин]

Пример я написал очень условный,

Даже слишком условный, не понять в чем у вас ошибка.
Примитивный пример использования.
ru.cppreference.com/w/cpp/thread/mutex
Также можете использовать
en.cppreference.com/w/cpp/thread/lock_guard
для автоматического lock/unlock в текущем скоупе.

Comments

[lightalex]

Суть в том что если сделать вот так:

locker.lock();
locker.lock();

то выдает исключение:

По логике ведь в данном случае на первом lock мьютекс должен заблокироваться, а на втором lock программа должна ждать пока он будет разблокирован, чтобы снова его заблокировать
Я ничего не путаю?
По сути если два раза подряд вызвать lock, то программа должна зависнуть, но не должно же вываливаться исключение? Или это какая-то система защиты от мертвой блокировки? Если так, то как ее обойти?

[Александр Таратин]

lightalex,
Нет. Из одного потока подряд lock вызывать нельзя.
https://rsdn.org/forum/cpp/6545265.hot
Вы пытаетесь сделать что-то странное.

[devalone]

lightalex,

По логике ведь в данном случае на первом lock мьютекс должен заблокироваться, а на втором lock программа должна ждать пока он будет разблокирован, чтобы снова его заблокировать
Я ничего не путаю?
По сути если два раза подряд вызвать lock, то программа должна зависнуть, но не должно же вываливаться исключение? Или это какая-то система защиты от мертвой блокировки? Если так, то как ее обойти?

Это всё описано в стандарте

If lock is called by a thread that already owns the mutex, the behavior is undefined: for example, the program may deadlock. An implementation that can detect the invalid usage is encouraged to throw a std::system_error with error condition resource_deadlock_would_occur instead of deadlocking.

[lightalex]

devalone, ну да
Поэтому и использовал костыль выше

[Александр Павлов]

lightalex, если я правильно понимаю, когда вы вызываете lock для конкретного mutex, то все остальные вызовы lock для данного mutex в других потоках будут ждать его освобождения.

То, что хотите сделать вы (два раза вызвать lock для одного пока) бессмысленно. Ведь вы уже заблокировали mutex, какой смысл его блокировать ещё раз.

Похоже, вы не понимаете для чего это необходимо, потому я советую вам почитать теорию по многопоточному программированию.

[lightalex]

Александр Павлов, я прекрасно понимаю что я хочу сделать
Ведь как вы уже наверное поняли, подразумевается что между двумя lock'ами произойдет unlock из вызванного потока
Это просто для примера я написал два раза подряд lock, для демонстрации исключения