Эти молодцы в бустах даже RTTI свой написали, а у меня очень сильная аллергия на велосипеды, когда C++17 на дворе.

Даже два. Второй тут: http://www.boost.org/doc/libs/1_66_0/doc/html/boost_typeindex.html

pragma once показывает на ряде компиляторов большую производительность, чем include guards. Другими словами - для того, чтобы ваш код препроцессировался быстрее

pragma once показывает на ряде компиляторов большую производительность, чем include guards. Другими словами - для того, чтобы ваш код препроцессировался быстрее

А обычный header guard — чтобы работало на компиляторе 98-ого года.

Люблю буст.

и поддерживают борландовские компиляторы

На это забили. Даже на MSVC-6 забили

Топ и к тому же хедер-онли

спс, ща порою

На это забили. Даже на MSVC-6 забили

СЛАВА БОГАМ

ну оно у меня так примерно и сделано было - мьютекс и два дека, но что-то ASan мне проел плешь что объект используется после удаления - пытаюсь понять что ему не нравится

А можно увидеть исходники? Оч интересно :)

https://github.com/cameron314/concurrentqueue

И за конан там топит не замазанчик :)

А можно увидеть исходники? Оч интересно :)

да, положу сейчас. у меня встречное предложение - положите вот это вот в буст https://github.com/cameron314/concurrentqueue

да, положу сейчас. у меня встречное предложение - положите вот это вот в буст https://github.com/cameron314/concurrentqueue

Два вискаса этому коту!

На это забили. Даже на MSVC-6 забили

NOOOO! Как я теперь смогу собирать на своем вин-98-пека с вц 6.0 проги с бустом?

Придётся ставить старенький буст

А можно увидеть исходники? Оч интересно :)

https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992 вот тут всё для воспроизведения проблемы

^ реквестирую ревью внимательными глазами

я три дня с ним уже ебусь и чот силы кончились

У меня есть многопоточный код, я хочу в тестах покрутить-повертеть, что будет в разных вариантах порядка выполнения операций. Я собираюсь решать это следующим образом: в код выполнения каждого потока я включаю некоторые вызовы, однозначно идентифицирующие место в коде, после чего включить отладочную среду, в рамках которой прохождение этих мест будет синхронизироваться и пропускаться так, как я скажу. Вопрос А: все уже сделано до меня? Вопрос Б: я правильно понимаю, что я беру mutex+condition_variable, беру DAG порядка выполнения, после чего узловая точка локает мутекс, записывает что достигнута в DAG, отпускает мутекс, вызывает notify_all, снова локает мутекс и вызывает wait на достижение всех предыдущих узловых в DAG?

У меня есть многопоточный код, я хочу в тестах покрутить-повертеть, что будет в разных вариантах порядка выполнения операций. Я собираюсь решать это следующим образом: в код выполнения каждого потока я включаю некоторые вызовы, однозначно идентифицирующие место в коде, после чего включить отладочную среду, в рамках которой прохождение этих мест будет синхронизироваться и пропускаться так, как я скажу. Вопрос А: все уже сделано до меня? Вопрос Б: я правильно понимаю, что я беру mutex+condition_variable, беру DAG порядка выполнения, после чего узловая точка локает мутекс, записывает что достигнута в DAG, отпускает мутекс, вызывает notify_all, снова локает мутекс и вызывает wait на достижение всех предыдущих узловых в DAG?

Для тестов многопоточного кода возьми relacy или ему подобное

Для тестов многопоточного кода возьми relacy или ему подобное

relacy выглядит ужасно, особенно учитывая переопределение new макросом в relacy.hpp :)

^ реквестирую ревью внимательными глазами

Я заметил потенциальный дедлок: Вот тут вызывается под локом метод, который лочит мьютекс WaitInfo https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L169 А вот тут https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L151 сначала лочится WaitInfo, а потом лочится основной мьютекс

https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992 вот тут всё для воспроизведения проблемы

>waitQueue_.erase(it, it); А не waitQueue_.erase(it, it+1)?

А вот утечку не нашёл

>waitQueue_.erase(it, it); А не waitQueue_.erase(it, it+1)?

нет, erase(it,it) это безопасный вариант erase(it), который не делает UB если std::find() вернул end()

А вот утечку не нашёл

оно не течёт, оно делает memory access after free

А вот утечку не нашёл

волшебным образом умудряется читать из unique_ptr который внутри WaitInfo после того как WaitInto удалился

придется почитать ассемблер еще, т.к. при -O0 всё работает, при -O1 падает к хуям

Точно? The iterator first does not need to be dereferenceable if first==last: erasing an empty range is a no-op.

Точно? The iterator first does not need to be dereferenceable if first==last: erasing an empty range is a no-op.

ХММ

спасибо, возможно тут и порылась проблема

>waitQueue_.erase(it, it); А не waitQueue_.erase(it, it+1)?

+1

спасибо, возможно тут и порылась проблема

https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L133

я плохо понимаю, кто его удалил из очереди

я плохо понимаю, кто его удалил из очереди

https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L168

https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L168

ну я сторонник того, чтобы delete выполнялся после удаления объекта из общей очереди

ну я сторонник того, чтобы delete выполнялся после удаления объекта из общей очереди

так и происходит

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

а, я понял

там окончание ожидания гарантирует, что он не в очереди

да

ну да, а во второй ветке, конечно, ошибка в случае таймаута

^ реквестирую ревью внимательными глазами

Там точно дедлок: Поток 1 наичанает выполнять эту строчку https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L155 Поток 2 вызывает https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L169 итого поток 1 держит waiting->cond_mutex_ и пытается залочить mutex_ поток 2 держит mutex_ и пытаетсчя залочить waiting->cond_mutex_

Там точно дедлок: Поток 1 наичанает выполнять эту строчку https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L155 Поток 2 вызывает https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L169 итого поток 1 держит waiting->cond_mutex_ и пытается залочить mutex_ поток 2 держит mutex_ и пытаетсчя залочить waiting->cond_mutex_

спс, ща покурю этот кусок, выглядит как дедлок

спс, ща покурю этот кусок, выглядит как дедлок

смотри, технически ты можешь завести себе std::array на 16 объектов value_type и 16 объектов ожидания

после чего через atomic выбирать из них элемент и если ты выбираешь 16, то блокируешься и подбираешь следующие 16 из дека

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

Там точно дедлок: Поток 1 наичанает выполнять эту строчку https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L155 Поток 2 вызывает https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L169 итого поток 1 держит waiting->cond_mutex_ и пытается залочить mutex_ поток 2 держит mutex_ и пытаетсчя залочить waiting->cond_mutex_

я так понимаю достаточно отпустить cond_lock в timeout ветке и всё будет ок

ну это зависит от

вообще я там выше постил вопрос про таймлайнилку

кажется, если ты разблокируешь waiting->cond_mutex_ до блокировки основного mutex_, тебе приедет параллельный поток с задачей и выдаст

т.е. там нужна будет еще проверка, что задачу не кикнули

кажется, если ты разблокируешь waiting->cond_mutex_ до блокировки основного mutex_, тебе приедет параллельный поток с задачей и выдаст

поясни как Полухин, ссылками и таймлайном

пока что я ничего не пони

только обнови гист а то там номера строк съедут

поясни как Полухин, ссылками и таймлайном

смотри, if (waiting->cond_.wait_for(cond_lock, timeout, [waiting] { return waiting->ready_.load(); })) { v = std::move(waiting->value_); } else { //разблокировать waiting->cond_mutex_ std::lock_guard<std::mutex> lock(mutex_); если перед выполнением этой блокировки ты разблокируешь waiting->cond_mutex_, то принципиально параллельный поток проходит полностью ветку void enqueue(DataType&& v) { enqueueWaitingLocked(std::move(item)); void enqueueWaitingLocked(value_type&& v) { waiting->signal_value(std::move(v)); void signal_value(value_type&& v) { std::unique_lock<std::mutex> lock(cond_mutex_); value_ = std::move(v); ready_ = true; cond_.notify_one(); } без блокировки, так что как минимум в этом случае тебе надо еще раз проверить, что параллельный поток не выдал тебе задачу после таймаута

но если он ее прошел - то всё ок же

вроде как да

дальше я залочу мьютекс очереди и выдерну из waiting положенный туда value ничего не потеряв

да, но ты должен перепроверить ready_ и выбрасывать ожидающего только если false

почему?

мне положили значение, я его забрал и успешно ушел

ERROR: S client not available

да, но в этом случае объект не находится в очереди ожидания

находится

он удалится после выполнения //разблокировать waiting->cond_mutex_ std::lock_guard<std::mutex> lock(mutex_);

вот этот поток вытащил его void enqueue(DataType&& v) { enqueueWaitingLocked(std::move(item)); void enqueueWaitingLocked(value_type&& v) { waitQueue_.pop_front(); //вот здесь waiting->signal_value(std::move(v)); void signal_value(value_type&& v) { std::unique_lock<std::mutex> lock(cond_mutex_); value_ = std::move(v); ready_ = true; cond_.notify_one(); }

ммм

так абажжи, то что он его вытащил из очереди, не значит что он там не находится - находился на момент вытаскивания и этого достаточно - он никуда уже не убежит

вообще если ты видишь ready_, то объекта точно нет в waitQueue_

а это и не обязательно

да, все в порядке

{ std::unique_lock<std::mutex> cond_lock(waiting->cond_mutex_); if (waiting->cond_.wait_for(cond_lock, timeout, [waiting] { return waiting->ready_.load(); })) v = std::move(waiting->value_); } if (v == nullptr) { std::lock_guard<std::mutex> lock(mutex_); v = std::move(waiting->value_); if (!waiting->ready_) { auto it = std::find(waitQueue_.begin(), waitQueue_.end(), waiting); waitQueue_.erase(it); } }

что-то такое

у тебя точная эквивалентность "!ready_ под блокировкой означает присутствие в очереди"

и да, кажется, ready_ не обязательно делать atomic

она под мьютексом меняется, но барьер неплохо бы

на cppreference есть прямо примеры, когда переменная для condition variable не atomic

я верю этим ребятам)

ага

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

она под мьютексом меняется, но барьер неплохо бы

Лок мьютекса это инвалидация ваще всего

А кто-то с движком Atomic Game Engine работал? Хочу через некоторое время перейти на него с Юнити. В официальном комьюнити уже зарегался, но ещё не освоился.

А в чем его прикол? Впервые слышу, прост.

Это форк от Урхо3Д. Один из двух форков с возможностью написания игрового кода на C#. Ну и полностью свободный код движка. В целом движок сам по себе не плох, но и не выдающийся. Чую, придётся искать решение для поднятия уровня графики.

А анриал енджейн?

Или не подходит? Вроде бы тоже не плох и поддкржка была от VS

1. Там же нет Си-шарп вроде. Я С++ только начал изучать. 2. Я перехожу в этом плане на опенсорс как на второй рабочий движок. В качестве условно-бесплатного остаюсь на Юнити. 3. Не думаю, что у меня сейчас есть возможность использовать графические фичи Анриала. А кроме них лично для себя плюсов сейчас не вижу.

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

1. Там же нет Си-шарп вроде. Я С++ только начал изучать. 2. Я перехожу в этом плане на опенсорс как на второй рабочий движок. В качестве условно-бесплатного остаюсь на Юнити. 3. Не думаю, что у меня сейчас есть возможность использовать графические фичи Анриала. А кроме них лично для себя плюсов сейчас не вижу.

Не, ну попробуй. Ток отпишись, как тебе движок.)

Ой, а вопросы по его установке через консоль не будут считаться здесь флудом? Я один раз устанавливал, но напутал с настройками. Буду устанавливать ещё раз как закончу текущие дела. Основу я вкурил, но пара деталей остались непонятными.

Ой, а вопросы по его установке через консоль не будут считаться здесь флудом? Я один раз устанавливал, но напутал с настройками. Буду устанавливать ещё раз как закончу текущие дела. Основу я вкурил, но пара деталей остались непонятными.

Это в @supapro или куда подальше