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

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

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

а, ну и отлично!

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

Залочивание мьютекса - это acquire барьер, разлочивание - release барьер Так что никаких лишних барьеров городить не надо

Залочивание мьютекса - это acquire барьер, разлочивание - release барьер Так что никаких лишних барьеров городить не надо

ну и отлично, а!

Залочивание мьютекса - это acquire барьер, разлочивание - release барьер Так что никаких лишних барьеров городить не надо

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

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

Пара хитростей из мастер класса о том как сделать вашу очередь более отзывчивой/быстрой: * зовите notify() не под локом - это сэкономит несколько переключаений контекста и улучшит отзывчивость * вместо деки для waitQueue используйте интрузивный список (сделайте WaitInfo классом, с указателем на след WaitInfo и у вас получится односвязный список) - сможете избежать динамических аллокаций * Напомните, чем вас не устраивает более простой вариант: https://github.com/apolukhin/Boost-Cookbook/blob/second_edition/Chapter05/04_work_queue/main.cpp#L7-L46 ?

Пара хитростей из мастер класса о том как сделать вашу очередь более отзывчивой/быстрой: * зовите notify() не под локом - это сэкономит несколько переключаений контекста и улучшит отзывчивость * вместо деки для waitQueue используйте интрузивный список (сделайте WaitInfo классом, с указателем на след WaitInfo и у вас получится односвязный список) - сможете избежать динамических аллокаций * Напомните, чем вас не устраивает более простой вариант: https://github.com/apolukhin/Boost-Cookbook/blob/second_edition/Chapter05/04_work_queue/main.cpp#L7-L46 ?

Спасибо, Антон! Сейчас поревьюю.

Пара хитростей из мастер класса о том как сделать вашу очередь более отзывчивой/быстрой: * зовите notify() не под локом - это сэкономит несколько переключаений контекста и улучшит отзывчивость * вместо деки для waitQueue используйте интрузивный список (сделайте WaitInfo классом, с указателем на след WaitInfo и у вас получится односвязный список) - сможете избежать динамических аллокаций * Напомните, чем вас не устраивает более простой вариант: https://github.com/apolukhin/Boost-Cookbook/blob/second_edition/Chapter05/04_work_queue/main.cpp#L7-L46 ?

в принципе WaitInfo я могу и на стеке выделять, и в интрузивный список сунуть да

Пара хитростей из мастер класса о том как сделать вашу очередь более отзывчивой/быстрой: * зовите notify() не под локом - это сэкономит несколько переключаений контекста и улучшит отзывчивость * вместо деки для waitQueue используйте интрузивный список (сделайте WaitInfo классом, с указателем на след WaitInfo и у вас получится односвязный список) - сможете избежать динамических аллокаций * Напомните, чем вас не устраивает более простой вариант: https://github.com/apolukhin/Boost-Cookbook/blob/second_edition/Chapter05/04_work_queue/main.cpp#L7-L46 ?

в частности в этой work_queue нету try_pop_task_for(ms)

Можно ли замокать Q_OBJECT гугловским gmock-ом?

Можно ли замокать Q_OBJECT гугловским gmock-ом?

http://arada-s.livejournal.com/2963.html

http://arada-s.livejournal.com/2963.html

Спасибо

Если есть вектор, и дано 8 тредов допустим. И мы делаем так что треды обрабатывают следующий свободный элемент, например 1й тред обрабатывает 1й, 2й -- 2й, а после освобождения, первый тред берет например 9й элемент, 2й -- 10й. Как такое правильно организуется? И лучше ли сделать если просто разбить вектор на 8 сегментов, и каждый обработать в каждом треде.

Если есть вектор, и дано 8 тредов допустим. И мы делаем так что треды обрабатывают следующий свободный элемент, например 1й тред обрабатывает 1й, 2й -- 2й, а после освобождения, первый тред берет например 9й элемент, 2й -- 10й. Как такое правильно организуется? И лучше ли сделать если просто разбить вектор на 8 сегментов, и каждый обработать в каждом треде.

обсуждение выше про очередь ты пропустил? вон Антон Полухин даже ссылку на правильную имплементацию дал

обсуждение выше про очередь ты пропустил? вон Антон Полухин даже ссылку на правильную имплементацию дал

да) пришел со своим вопросом. Сейчас почитаю, спасибо

Если есть вектор, и дано 8 тредов допустим. И мы делаем так что треды обрабатывают следующий свободный элемент, например 1й тред обрабатывает 1й, 2й -- 2й, а после освобождения, первый тред берет например 9й элемент, 2й -- 10й. Как такое правильно организуется? И лучше ли сделать если просто разбить вектор на 8 сегментов, и каждый обработать в каждом треде.

если ты просто берешь каждый 8-й элемент то никаких проблем нет и даже синхронизация не нужна (если ты вектор не модифицируешь)

просто в воркер треде берешь for (int i = 0; i < SOME_VALUE; ++i) { process(vector[i*8]); }

в частности в этой work_queue нету try_pop_task_for(ms)

вы мне подкинули идею. Надо мне сделать репозиторий с наборами готовых С++11 решений по самым популярным вопросам: * многопоточная очередь * как форсить rvalue, вместо perfect forwarding * case insensitive string/string_view * slab_allocator * private constructors + static shared_ptr crete() * circular_iterator * using heterogenous_map = std::map * fallback overload + specializations без enable_if * interruptable thread * coroutines ts: корутина, взаимодействующая с многопоточной очередью * boost: asserts with stacktrace * boost: simple spirit example * boost: graph parsing * ...

вы мне подкинули идею. Надо мне сделать репозиторий с наборами готовых С++11 решений по самым популярным вопросам: * многопоточная очередь * как форсить rvalue, вместо perfect forwarding * case insensitive string/string_view * slab_allocator * private constructors + static shared_ptr crete() * circular_iterator * using heterogenous_map = std::map * fallback overload + specializations без enable_if * interruptable thread * coroutines ts: корутина, взаимодействующая с многопоточной очередью * boost: asserts with stacktrace * boost: simple spirit example * boost: graph parsing * ...

Я двумя ногами за и готов помочь всеми силами

вы мне подкинули идею. Надо мне сделать репозиторий с наборами готовых С++11 решений по самым популярным вопросам: * многопоточная очередь * как форсить rvalue, вместо perfect forwarding * case insensitive string/string_view * slab_allocator * private constructors + static shared_ptr crete() * circular_iterator * using heterogenous_map = std::map * fallback overload + specializations без enable_if * interruptable thread * coroutines ts: корутина, взаимодействующая с многопоточной очередью * boost: asserts with stacktrace * boost: simple spirit example * boost: graph parsing * ...

можно только коррекцию, пусть это будут С++14 или С++17 решения?

можно только коррекцию, пусть это будут С++14 или С++17 решения?

мне кажется, имелось в виду C++11+ =)

Да там большинство вопросов в с++11 решаются без проблем. C++17 фишки тоже можно закинуть

вы мне подкинули идею. Надо мне сделать репозиторий с наборами готовых С++11 решений по самым популярным вопросам: * многопоточная очередь * как форсить rvalue, вместо perfect forwarding * case insensitive string/string_view * slab_allocator * private constructors + static shared_ptr crete() * circular_iterator * using heterogenous_map = std::map * fallback overload + specializations без enable_if * interruptable thread * coroutines ts: корутина, взаимодействующая с многопоточной очередью * boost: asserts with stacktrace * boost: simple spirit example * boost: graph parsing * ...

да, что-то вроде этого было бы здорово https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms

Да, только с кодом и попрактичнее

в частности в этой work_queue нету try_pop_task_for(ms)

Это-то как раз просто добавляется. А вот зачем использовать отдельную condition_variable на каждый pop?

Это-то как раз просто добавляется. А вот зачем использовать отдельную condition_variable на каждый pop?

Кто-то тут гордился поко - это вот к вопросу о говнокоде https://github.com/pocoproject/poco/blob/develop/Foundation/src/NotificationQueue.cpp#L103

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

Да там большинство вопросов в с++11 решаются без проблем. C++17 фишки тоже можно закинуть

Кстати, вопрос, а что вот с этой либой? http://htmlpreview.github.io/?https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/doc/asynchronous.html она будет куда-то двигаться?

я её вижу в первый раз :)

Мужчины, а посоветуйте годный быстрый rwlock aka shared_mutex на c++11

Мужчины, а посоветуйте годный быстрый rwlock aka shared_mutex на c++11

Быстрых rw локов не бывает

Я так и думал...

ERROR: S client not available

бот?

А как решить тогда такую задачку - есть куча читателей которые постоянно читают и есть один писатель который пишет крайне редко буквально раз в минуту и реже, читатели читают каждые 30ms...

spmc... хмм

Сейчас системный рвлок стоит

А как решить тогда такую задачку - есть куча читателей которые постоянно читают и есть один писатель который пишет крайне редко буквально раз в минуту и реже, читатели читают каждые 30ms...

пробовал просто гуглить по spmc queue?

там вариантов чот многа

http://moodycamel.com/blog/2014/detailed-design-of-a-lock-free-queue вот например чел который вчера всплывал

А как решить тогда такую задачку - есть куча читателей которые постоянно читают и есть один писатель который пишет крайне редко буквально раз в минуту и реже, читатели читают каждые 30ms...

есть userspace rcu, но я им ни разу не пользовался: http://liburcu.org/

> Then there's a small base class for the two types of internal SPMC producer queues (one for explicit producers that holds onto memory but attempts to be faster, and one for implicit ones which attempt to recycle more memory back into the parent but is a little slower) https://github.com/cameron314/concurrentqueue

> Then there's a small base class for the two types of internal SPMC producer queues (one for explicit producers that holds onto memory but attempts to be faster, and one for implicit ones which attempt to recycle more memory back into the parent but is a little slower) https://github.com/cameron314/concurrentqueue

а если чтение/запись не последовательна?

а если чтение/запись не последовательна?

ну тут я хз

с очередями у меня не очень хорошо еще с советских времён /shrug

Спасибо, буду думать. Пока вариант с сисколами вроде справляется, задел на будущее смотрю

https://t.me/ProCxx/8

извините. ностальгирую

а если чтение/запись не последовательна?

для этой очереди без разницы