Дай бог побольше нервов людям, которым приходится поддерживать C++98.
да, что ж поделать
Alexander "SonnySlave"
Anonymous
The header <boost/core/typeinfo.hpp> defines a class boost::core::typeinfo, which is an alias for std::type_info when RTTI is enabled, and is a reasonable substitute when RTTI is not supported.
Вот тогда такой вопрос, как, скажем в C++98 можно уникально идентифицировать тип?
Berkus
Эти молодцы в бустах даже RTTI свой написали, а у меня очень сильная аллергия на велосипеды, когда C++17 на дворе.
у Хижинского даже лицензия вменяемая, так что очень хороший кандидат
Alexander "SonnySlave"
у Хижинского даже лицензия вменяемая, так что очень хороший кандидат
ну Хижинский сам по себе дядька очень интересный
Kirill
Дай бог побольше нервов людям, которым приходится поддерживать C++98.
Хочется аналог typeindex из мира до с++11?
Kirill
Вот тогда такой вопрос, как, скажем в C++98 можно уникально идентифицировать тип?
Это сюда ответ был :)
Anonymous
Совсем без понятия, как можно полиморфные типы идентифицировать, имея указатель на базовый.
Anonymous
Berkus
Berkus
и поддерживают борландовские компиляторы
Berkus
поэтому такая хуйня
Berkus
короче, очередей в бусте до жопы и все хуевые донельзя
Anonymous
короче, очередей в бусте до жопы и все хуевые донельзя
А что у них там хуевого? Я просто рассматривал, как кандидата, чтобы заменить блокирующую очередь в своём чудо-проекте.
Berkus
есть и в boost.thread, и в boost.log и в boost.lockfree, и еще где-то забыл уже где
Berkus
А что у них там хуевого? Я просто рассматривал, как кандидата, чтобы заменить блокирующую очередь в своём чудо-проекте.
ну например в лок фри они требуют тривиального деструктора для элементов
Berkus
все из них требуют CopyConstructible мне нахуй не нужный
Berkus
ни один из них не поддерживает даже близко нужный мне апи
Berkus
bool empty() const {
size_t size() const {
void clear() {
void wakeUpAll() {
void enqueue(value_type&& v) {
void enqueueUrgent(value_type&& v) {
template <typename ...Args>
void emplace(Args&&...args) {
template <typename ...Args>
void emplaceUrgent(Args&&...args) {
value_type dequeue() {
value_type waitDequeue() {
value_type waitDequeue(std::chrono::milliseconds timeout) {
вроде не слишком много прошу?
Anonymous
По-моему ты просишь очередь и condition_variable в одном классе.
Berkus
ну оно у меня так примерно и сделано было - мьютекс и два дека, но что-то ASan мне проел плешь что объект используется после удаления - пытаюсь понять что ему не нравится
Vyacheslav
#book
https://www.piter.com/collection/new/product/linux-api-ischerpyvayuschee-rukovodstvo
Ostap ꑭ
1248 страниц, исчерпывающее
Square
нужна дженерик очередь, multi-producer multi-consumer, желательно где-нибудь в бусте.
https://github.com/cameron314/concurrentqueue
Square
Топ и к тому же хедер-онли
Square
Есть тесты против буста/интела/ и прочих
🐙 Antony
Эти молодцы в бустах даже RTTI свой написали, а у меня очень сильная аллергия на велосипеды, когда C++17 на дворе.
Даже два. Второй тут: http://www.boost.org/doc/libs/1_66_0/doc/html/boost_typeindex.html
🐙 Antony
Anonymous
pragma once показывает на ряде компиляторов большую производительность, чем include guards. Другими словами - для того, чтобы ваш код препроцессировался быстрее
А обычный header guard — чтобы работало на компиляторе 98-ого года.
Anonymous
Люблю буст.
🐙 Antony
ну оно у меня так примерно и сделано было - мьютекс и два дека, но что-то ASan мне проел плешь что объект используется после удаления - пытаюсь понять что ему не нравится
А можно увидеть исходники? Оч интересно :)
Berkus
А можно увидеть исходники? Оч интересно :)
да, положу сейчас. у меня встречное предложение - положите вот это вот в буст https://github.com/cameron314/concurrentqueue
Square
🦥Alex Fails
На это забили. Даже на MSVC-6 забили
NOOOO! Как я теперь смогу собирать на своем вин-98-пека с вц 6.0 проги с бустом?
🐙 Antony
Придётся ставить старенький буст
Berkus
А можно увидеть исходники? Оч интересно :)
https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992 вот тут всё для воспроизведения проблемы
Berkus
^ реквестирую ревью внимательными глазами
Berkus
я три дня с ним уже ебусь и чот силы кончились
Constantine
У меня есть многопоточный код, я хочу в тестах покрутить-повертеть, что будет в разных вариантах порядка выполнения операций.
Я собираюсь решать это следующим образом: в код выполнения каждого потока я включаю некоторые вызовы, однозначно идентифицирующие место в коде, после чего включить отладочную среду, в рамках которой прохождение этих мест будет синхронизироваться и пропускаться так, как я скажу.
Вопрос А: все уже сделано до меня?
Вопрос Б: я правильно понимаю, что я беру mutex+condition_variable, беру DAG порядка выполнения, после чего узловая точка локает мутекс, записывает что достигнута в DAG, отпускает мутекс, вызывает notify_all, снова локает мутекс и вызывает wait на достижение всех предыдущих узловых в DAG?
Constantine
Для тестов многопоточного кода возьми relacy или ему подобное
relacy выглядит ужасно, особенно учитывая переопределение new макросом в relacy.hpp :)
🐙 Antony
^ реквестирую ревью внимательными глазами
Я заметил потенциальный дедлок:
Вот тут вызывается под локом метод, который лочит мьютекс WaitInfo https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L169
А вот тут https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L151 сначала лочится WaitInfo, а потом лочится основной мьютекс
Arseny
https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992 вот тут всё для воспроизведения проблемы
>waitQueue_.erase(it, it);
А не waitQueue_.erase(it, it+1)?
🐙 Antony
А вот утечку не нашёл
Berkus
>waitQueue_.erase(it, it);
А не waitQueue_.erase(it, it+1)?
нет, erase(it,it) это безопасный вариант erase(it), который не делает UB если std::find() вернул end()
Berkus
А вот утечку не нашёл
волшебным образом умудряется читать из unique_ptr который внутри WaitInfo после того как WaitInto удалился
Berkus
придется почитать ассемблер еще, т.к. при -O0 всё работает, при -O1 падает к хуям
Arseny
Точно?
The iterator first does not need to be dereferenceable if first==last: erasing an empty range is a no-op.
Berkus
спасибо, возможно тут и порылась проблема
Constantine
спасибо, возможно тут и порылась проблема
https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L133
Constantine
я плохо понимаю, кто его удалил из очереди
Berkus
я плохо понимаю, кто его удалил из очереди
https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L168
Constantine
https://gist.github.com/berkus/fddcd55b865e1c24f48009cf380cd992#file-notificationqueue-h-L168
ну я сторонник того, чтобы delete выполнялся после удаления объекта из общей очереди
Berkus
Berkus
этот WaitInfo вообще можно на стеке аллоцировать, что я подумываю сделать чтобы в кучу не ходить лишний раз
Constantine
а, я понял
Constantine
там окончание ожидания гарантирует, что он не в очереди
Berkus
да
Constantine
ну да, а во второй ветке, конечно, ошибка в случае таймаута
🐙 Antony
^ реквестирую ревью внимательными глазами
Там точно дедлок:
Поток 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_
Berkus
Там точно дедлок:
Поток 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_
спс, ща покурю этот кусок, выглядит как дедлок
Constantine
спс, ща покурю этот кусок, выглядит как дедлок
смотри, технически ты можешь завести себе std::array на 16 объектов value_type и 16 объектов ожидания
Constantine
после чего через atomic выбирать из них элемент и если ты выбираешь 16, то блокируешься и подбираешь следующие 16 из дека
Constantine
видимо, тебе еще будет нужна переменная с текущим состоянием "есть задачи, есть исполнители, нет ничего"
Berkus
Там точно дедлок:
Поток 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 ветке и всё будет ок
Constantine
ну это зависит от
Constantine
вообще я там выше постил вопрос про таймлайнилку
Constantine
кажется, если ты разблокируешь waiting->cond_mutex_ до блокировки основного mutex_, тебе приедет параллельный поток с задачей и выдаст
Constantine
т.е. там нужна будет еще проверка, что задачу не кикнули
Berkus
кажется, если ты разблокируешь waiting->cond_mutex_ до блокировки основного mutex_, тебе приедет параллельный поток с задачей и выдаст
поясни как Полухин, ссылками и таймлайном
Berkus
пока что я ничего не пони