Mutex'сы - как их правильно готовить

Чтение кода - за деньги. Конкретный вопрос есть?

man pthread_mutex_init

или как выше предложили - в job, там любой каприз за ваши деньги

даже по приведённой ссылке неясно что за вопрос. Кроме того что реализация «class Log» пользуется успехом на LOR

что неправильно, чего не хватает.

Довольно ужасный код, голова болит от него… Микс разных подходов, проблемы с синхронизацией, видна попытка сделать асинхронный логгер, но жёсткий мьютекс закрывающий запись логов всё равно делает всё по сути последовательным… 😖

Правильно писать код без мьютексов

Вопрос, собственно, что неправильно, почему, как исправить

дВ чем проблемы с синхронизацией?

Какой мьютекс вы считаете жестким?

Как сделать (правильно) асинхронный логгер?

Как сделать (правильно) асинхронный логгер?

Нарисуйте на листочке временную диаграмму процессов, чтобы представить что с чем должно работать параллельно. Вполне может быть, что асинхронность даже и не нужна будет…

Это не конкретный вопрос, это «сделайте мне код ревью».

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

Да, наверно, можно считать и так. Сейчас читаю Уильямса, «Паралельное программирование на С++» и пробую применить прочитанное. Вот и интересно мнение людей, более знающих, чем я.

25. if (!m_logger.get()) m_logger.reset(new Logger);

Первый раз вижу, чтобы так делали синглтоны. Гонка потоков.

33. if (m_messages.size() > m_limit) m_cond_var.notify_one();

notify_one нужно вызывать с уже разблокированным мьютексом.

41. for (list::const_iterator it = m_messages.begin(); it != m_messages.end(); ++it)

range based for loop

40. lock_guard lock(m_mut);

46. unique_lock ul(m_cond_var_mutex);

Два презерватива на всякий пожарный? Зачем столько мьютексов?

47. m_cond_var.wait_for(ul, chrono::seconds(m_interval));

Без предиката не рекомендуется использовать wait. Потому что может быть ложные пробуждение.

50. break;

51. flush_log();

Мёртвый код.

И ещё пару мест, которые мне лень копипастить.

Короче полностью переписать.

Для начала откажитесь от использования метафоры «готовить». Это не кухня.

Хорошо

notify_one нужно вызывать с уже разблокированным мьютексом.

Спасибо

Два презерватива на всякий пожарный? Зачем столько мьютексов?

Исправлю.

Без предиката не рекомендуется использовать wait. Потому что может быть ложные пробуждение.

Хорошо, посмотрю.

Спасибо!

Микс разных подходов

Простите, забыл спросить: в чем это выражается?

Первый раз вижу, чтобы так делали синглтоны. Гонка потоков.

Это как раз абсолютно нормально. Главное дёрнуть разок до того как треды начали форкаться, и потом экономить на синхронизации.

Но согласен - код в оригинальном виде кривенький донельзя. Учится человек пока, это ожидаемо. Могло было быть гораздо хуже.

Это как раз абсолютно нормально. Главное дёрнуть разок до того как треды начали форкаться, и потом экономить на синхронизации.

Да, этот поток запускается первым.

Но согласен - код в оригинальном виде кривенький донельзя. Учится человек пока, это ожидаемо. Могло было быть гораздо хуже.

Вот еще бы с уточнением рабиуса кривизны, а?

1. if (m_messages.size() > m_limit) m_cond_var.notify_one();

notify_one нужно вызывать с уже разблокированным мьютексом.

cpp.reference.com:

When a lock_guard object is created, it attempts to take ownership of the mutex it is given. When control leaves the scope in which the lock_guard object was created, the lock_guard is destructed and the mutex is released.

Как его разблокировать? Что-то вроде

{
    lock_guard<mutex> lock(m_mut);
    push_back(_msg);
}
if (m_messages.size() > m_limit) m_cond_var.notify_one();

Типа того.

Главное дёрнуть разок до того как треды начали форкаться

Это знание, явно не выраженное в коде. Забудешь про это требование или другой человек придёт и всё сломается.

Предлагаю get_logger() переделать на синглтон Майерса и переименовать в get_instance(). Название get_instance() намекнет пользователю что класс синглтон.

static Logger* get_instance()
{
    static Logger logger;
    return &logger;
}

Для защиты данных и condition_vatiable нужно использовать один mutex.
Лучше использовать condition_vatiable::wait() с предикатом.

https://en.cppreference.com/w/cpp/thread/condition_variable
Any thread that intends to wait on a std::condition_variable must:
Acquire a std::unique_lockstd::mutex on the mutex used to protect the shared variable
Do one of the following:

1. Check the condition, in case it was already updated and notified \
2. Call wait, wait_for, or wait_until on the std::condition_variable (atomically releases the mutex and suspends thread execution until the condition variable is notified, a timeout expires, or a spurious wakeup occurs, then atomically acquires the mutex before returning) \
3. Check the condition and resume waiting if not satisfied

or:
Use the predicated overload of wait, wait_for, and wait_until, which performs the same three steps

Еще пояснение о том как condition_vatiable использует mutex
https://ru.stackoverflow.com/questions/1279013/condition-variable-c
https://habr.com/ru/post/182626/

Вот еще бы с уточнением радиуса кривизны, а?

Вам мало того что уже написали? Если Вас интересует конкретно мой input - имеем дело с кучей лишних телодвижений, ненужных mallocs и (что более важно) - syscall’ами, и безосновательно длинными критическими секциями. Не так обычно логеры пишут, совсем не так.

Предлагаю get_logger() переделать на синглтон Майерса

Настоятельно рекомендую хотя бы одним глазком посмотреть в какой asm это развернётся. Один «лишний» conditional jump в предложенном решении - way better. Ну, и при желании, даже его можно было бы избежать.

Посмотрел.
https://godbolt.org/z/5GnvM1rdq

Ничего плохого не вижу. Можете указать на проблему?

Mutex’сы - как их правильно готовить

• спрашиваешь свободен ли mutex
  • ждёшь
    • захватываешь mutex
      • захватываешь данные на которое он «наложен»
        • теперь все ждут тебя
          • отдаёшь mutex
            • теперь mutex захвачен другим
              • делаешь свои дела дальше и если снова нужны данные
                • спрашиваешь свободен ли mutex
                  • ждёшь

И так по кругу до сегфолта :D

Ничего плохого не вижу. Можете указать на проблему?

«Просто добавь воды (конструктор)». Кардинально отличается, не правда ли?

Добавил конструктору тельце чтобы линкер не ругался.
https://godbolt.org/z/sv1hKhdMj
Посмотрел еще раз. Добавился код для конструктора и гарды чтобы вызов instance() был потокобезопасным. Вас гарды смущают?

Вас гарды смущают?

Да, смущают. Пипец как смущают. Это call, и в лучшем случае лишние atomics. Там где пары инструкций должно было хватить. Но, возможно, у Вас другие критерии. И вообще - я попИсать вышел.

Мой Вам совет: начните изучение сразу с lock-free алгоритмов, да и вообще темы неблокирукирующей синхронизации. Один раз сломаете мозг об неё, зато потом, понимание взаимодействий потоков не будет вызывать никаких сложностей.

Так дай ссылки что почитать в PDF. От себя рекомендую изучить новичкам сишникам яблочную libdispatch

Так дай ссылки что почитать в PDF.

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

Я начинал знакомство с серии статей «Lock-free структуры данных». В этой серии, кстати, приводится много ссылок на другие источники.
Про протоколы когерентности кешей есть хорошая статья «Принципы работы кэш-памяти».
Для первичного ознакомления с терминологией стоит прочитать вот это «Akka Documentation: Terminology, Concepts».
Обязательно к прочтению классика от Лесли Лэмпорта: «Time, Clocks, and the Ordering of Events in a Distributed System» и «How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs». Остальные его работы смотрите в списке его публикаций.
Начать знакомство с самими lock-free структурами данных стоит со Стека Трайбера и Очереди Майкла и Скотта.
Продолжите знакомством с алгоритмом LCRQ Адама Моррисона. Остальные его публикации. После знакомства с LCRQ, возможно Вы, как и многие до Вас, переизобретёте колесо алгоритм FAA Array Queue. Ваш покорный слуга тоже не избежал этой участи…
Кроме того, советую заглянуть на страничку публикаций Майкла Ли Скотта, там можно найти много интересного. Например продвинутый вариант алгоритма LCRQ - алгоритм MPDQ. На основе этого алгоритма можно улучшить и FAA Array Queue.

std::thread уже не модно. jthread и stop_token - наше всё.

Не надо писать «using std» и снимать квалификацию.

Не надо писать std::string, а написать разок навроде

using logString = std::string

и использовать потом везде алиас logString.

Понатыкивать везде длинные квалификации навроде std::tratata::trututu… - это моветон. это плохо читается и лишний раз подчеркивает ненужные особенности расположения каких-то обьектов, до которой вашей программе дела нет.

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

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

Используйте алиасы и отвязывайтесть от библиотечной плюсовой конкретики.

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

Часто говорят, что с++ - сложный язык… но это впечатление во многом связано с тем, что люди пишут простые вещи слишком сложно и слишком прибито к стандртным либам.

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

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

Пишите комменты к функциям, отличным от тривиальных, хотя бы краткие. код без комментов - мусорный.

Охренеть… Это реально Ваши заповеди??

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

и использовать потом везде алиас logString.

Используйте алиасы и отвязывайтесть от библиотечной плюсовой конкретики.

Хороший совет (нет). Тогда тебя не никогда смогут уволить, потому что никто не сможет понять, что это за MySuperPuperString и MySuperPuperMap и пара-тройка десятков других алиасов/классов в твоем коде.

Дык. Если бы не Ваша откровенная чушь - да и фиг бы с вами. Но вы же как черт из табакерки… А ведь молодежь может и повестись.

что это за MySuperPuperString и MySuperPuperMap и пара-тройка десятков других алиасов/классов в твоем коде

нет ниакакой разницы между MySuperPuperString и MySuperPuperClass или MySuperPuperVar. вы и имена не будете давать классам и переменным? это же опасно, не так ли.

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

зы. а если вдруг понадобится вариант кода для std::wstring или вроде того… вы что будете делать-то? копипейстить и править на новый тип, или просто измените алиас? код такого рода уж точно не должен зависеть от представления строк.

нет ниакакой разницы между MySuperPuperString и MySuperPuperClass или MySuperPuperVar.

Конечно, есть разница. Когда я вижу std::string, я точно знаю, что я могу с ним делать, где посмотреть документацию, и т.д. А когда я вижу твой logString, я не знаю ничего. Более того, если у тебя в одной части кода logString, а в другой какой-нибудь тип webString, то хрен его знает, один ли и тот же это тип или разные, и как мне передать logString туда, где хотят webString. Это называется каша.

Причем, в языках, отличных от С++, такая хрень не распространена. Везде используются стандартные типы. И правильно делают, зачем изобретать свою кривую систему базовых типов? Но почему-то в С++ как нагородят-нагородят, а потом еще и жалуются, какой мол С++ корявый язык.

Когда я вижу std::string, я точно знаю, что я могу с ним делать

аргумент вида - когда я вижу int я точно знаю что с ним делать. потому кроме int, других типов не нужно.

Более того, если у тебя в одной части кода logString, а в другой какой-нибудь тип webString, то хрен его знает,…

если типы разные - значит скорее всего они разные не просто так. а преобразование типов описывается в рамках с++.

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

открой фреймфорк QT, и посмотри сколько там своих «базовых типов» включая QString. и откуда следует, что std:: типы - «прямые»? для нормальной работы их обычно надо допиливать до вменяемого состояния. фреймворки наоборот любят запилить свои типы, чтобы отвязаться от хотелок комитета по стандартизации с++.

Вас гарды смущают?

Да, смущают. Пипец как смущают. Это call, и в лучшем случае лишние atomics.

Согласен, меня тоже смущают. Поэтому использую так:

Singleton *s = Singleton::instance();

for (...)
    s->work();

Согласен, меня тоже смущают.

А теперь - внимание, вопрос! Если мы договорились что такой singleton имеет noticeable overhead - зачем в принципе его (overhead) изначально приносить и потом с ним бороться?

При любом способе организации синглтона вызов instance() - оверхед. И способ борьбы с этим оверхедом - редко вызывать instance().

А теперь - внимание, вопрос! Если мы договорились что такой singleton имеет noticeable overhead - зачем в принципе его (overhead) изначально приносить и потом с ним бороться?

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

в данном случае такие синглетоны - плата за отсутствие модулей в плюсах.

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

открой фреймфорк QT, и посмотри сколько там своих «базовых типов»

Ололо, отличная идея отсылать к фреймворку, базовые названия и стайлгайды которого формировались когда в стандарте не было половины текущего функционала. Да, откройте сорцы Qt и посмотрите, какой там повсюду говнокод. Его только-только начали причесывать, но все бесконечные ни с чем не совместимые QString и QByteArray никуда не денутся.

хотелок комитета по стандартизации с++.

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

Ололо, отличная идея отсылать к фреймворку, базовые названия и стайлгайды которого…

прекрасно. называешь свой любимый нормальный(не забытую поделку пары человек)фреймфорк, и мы смотрим его сорсы и типы.

STL.

Где я написал, что «Qt говно, а вот ххх - заебись?». Qt - говно, потому что полон легаси, которое писалось в допотопные времена. Ни больше, ни меньше. И относиться к нему как к «эталону продуманности» глупо.

STL - не фреймворк, а библиотека шаблонов. или по вашему STL закрывает тему фреймворков и все кроме stl должно быть выброшено в мусорку, поскольку этой самой STL теперь хватит на все случаи жизни?

вы настаиваете, что алиасы типов не нужны в принципе, одновременно утверждая, что в комитете по с++ собрались умные головы? так они алиасы и вводили.

пишите, как угодно, строго на STL, если вам этого хватает, вряд ли кто будет тут возражать

утверждая, что в комитете по с++ собрались умные головы

Ну так а зачем вы пишете на языке, который, по вашему мнению, разработали идиоты?