Могопоточное приложение на C++

[Fortune1Coin]

Многопоточное приложение на C++ с использованием Boost.ASIO.

Разыскивается опытный разработчик в указанной области.
Задача: перевести приложение с однопоточного режима во многопоточный.

[1714152825]

1714152825

[kzv]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

[Fortune1Coin]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

В данном случае, это не блаж - это необходимость.

[kzv]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

В данном случае, это не блаж - это необходимость.

Откуда такая уверенность?
И чем обусловлен выбор Boost.ASIO вместо например libev?
Если что-то нужно распараллелить, то делить надо не на потоки, а на процессы. А параллелить внутри процесса.., ну я даже не могу представить себе для чего это может реально понадобиться... Разве что для какого-то специфичного стресс-теста многоядерного процессора.

[Fortune1Coin]

Примерно в 100% случаев, многопоточность делает приложению только хуже.

В данном случае, это не блаж - это необходимость.

Откуда такая уверенность?
И чем обусловлен выбор Boost.ASIO вместо например libev?
Если что-то нужно распараллелить, то делить надо не на потоки, а на процессы. А параллелить внутри процесса.., ну я даже не могу представить себе для чего это может реально понадобиться... Разве что для какого-то специфичного стресс-теста многоядерного процессора.

ASIO - так исторически сложилось. Делали форк с Bytecoin, там ASIO.
На одном ядре приложение захлебывается. В настоящее время самый оптимальный пусть масштабирования - это многопоточность (что бы потом можно было масштабировать производительность путем наращивания процессорных мощностей). Но столкнулись с проблемой при переходе на многопоточный режим ASIO. Нужен скилованный специалист, что бы оперативно решить вопрос, т.к. у самих получается медленно.

Про стресс-тест вообще не понял. ИМХО - неуместный сарказм. Многопоточность только для стресс-тестов придумывали что-ли?

[kzv]

Я вам даю 100% гарантию, что при переходе на многопоточный режим, ваше приложение начнет "захлебываться" еще сильнее.
Смотрите лучше в сторону оптимизации архитектуры. Многопоточность придумывали в те времена, когда еще были споры что лучше: многопоточность или асинхронность. К настоящему времени опытным путем давно установлено, что асинхронность всегда лучше.
Разрабы биткоина кстати уже несколько лет пытаются окончательно выпилить boost из исходников, так что стоит задуматься: а вам оно точно надо?

[eXtremal.ik71]

Если что-то нужно распараллелить, то делить надо не на потоки, а на процессы. А параллелить внутри процесса.., ну я даже не могу представить себе для чего это может реально понадобиться... Разве что для какого-то специфичного стресс-теста многоядерного процессора.

Смотрите лучше в сторону оптимизации архитектуры. Многопоточность придумывали в те времена, когда еще были споры что лучше: многопоточность или асинхронность. К настоящему времени опытным путем давно установлено, что асинхронность всегда лучше.

Это смотря какой язык используется, если Python то из-за его особенностей это все правда, но в контексте C++ написанное выглядит полным бредом Вот как можно противопоставлять многопоточность и асинхронность? Возьмем nginx, он асинхронный и многопоточный, в его конфиге указывается число рабочих потоков, и во многих случаях производительность линейно масштабируется в зависимости от кол-ва потоков.

[kzv]

но в контексте C++ написанное выглядит полным бредом Вот как можно противопоставлять многопоточность и асинхронность? Возьмем nginx, он асинхронный и многопоточный, в его конфиге указывается число рабочих потоков, и во многих случаях производительность линейно масштабируется в зависимости от кол-ва потоков.

Не порите чушь, ей больно ))
Противопоставлять многопоточность и асинхронность можно очень даже запросто и от языка программирования тут мало что зависит.
Не берите нгинкс, а напишите свой сервер в двух вариантах: в асинхронном и в многопоточном. Когда напишете - приходите, поговорим  

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

[eXtremal.ik71]

Что, прямо так мало задач распараллеливается?
Если посмотреть тест многоядерных процессоров (например 32-ядерного AMD) https://www.anandtech.com/show/15044/the-amd-ryzen-threadripper-3960x-and-3970x-review-24-and-32-cores-on-7nm то видно, что не так и мало бенчмарков, где он обгоняет обычные 6-8 ядерники с большим отрывом.
Серверы распарралеливаются почти все (не только веб), что мешает одновременно обрабатывать запросы от нескольких клиентов?
И причем тут вообще асинхронность? Та же упомянутая библиотека boost.asio позволяет запускать цикл обработки сообщений о завершенных операциях отправки/приема данных, ничто не мешает запустить таких потоков по количеству ядер, и обрабатывать эти сообщения одновременно.

[kzv]

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

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

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

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

Раз уж мы тут на криптофоруме, то можно порассуждать какая архитектура у биткоин коры... Так вот, если быть откровенном, то глядя на код который отвечает за клиент-серверное взаимодействие в коре, складывается устойчивое ощущение что сетевая архитектура у коры написана левой пяткой каким-то школьником, который первый раз в жизни вообще сетевое приложение пишет! Это ощущение складывается именно из-за кривой даже для 2007 года (когда Сатоши по его словам начал работать над кодом) многопоточности.
Хотя если допустить, что Сатоши это Ник Сабо, то ничего удивительного - он ни разу не кодер, а скорее научный руководитель и вдохновитель ))

[Balthazar]

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

Биткойн клиент ещё при Гэвине был капитальным говнокодом, от изучения которого хотелось пустить себе 9 мм в лоб. Чего стоит синхронный броадкаст блоков, к примеру... Анонсируем блок одной ноде, получаем ответ, затем шлем блок если запросили. Потом шлем анонс следующей ноде, получаем ответ, затем шлем блок уже ей, если запросили. И так для каждого из подключенных пиров, последовательно, после чего каждый пир проделает этот же процесс уже для своих пиров. А то, что обмен данными с одним пиром никак не помешает обменяться этими же данными с другим пиром, автору в голову почему-то не пришло.



Радует, что всё это уже давно переписано и забыто.

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

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

[eXtremal.ik71]

Раз уж мы тут на криптофоруме, то можно порассуждать какая архитектура у биткоин коры... Так вот, если быть откровенном, то глядя на код который отвечает за клиент-серверное взаимодействие в коре, складывается устойчивое ощущение что сетевая архитектура у коры написана левой пяткой каким-то школьником, который первый раз в жизни вообще сетевое приложение пишет! Это ощущение складывается именно из-за кривой даже для 2007 года (когда Сатоши по его словам начал работать над кодом) многопоточности.

Код для работы с сетью в bitcoin core вполне себе асинхронный и всегда им был (раньше использовал системный вызов select, сейчас вроде как libevent, хотя на 100% не уверен), но оптимизированным его назвать сложно, т.к. он при обработке сообщения захватывает мьютекс cs_main, т.е. фактически однопоточный.

Однако же, ничто не мешает реализовать асинхронное многопоточное приложение, если это действительно нужно. Главное - это иметь в виду, что оно не должно реализовываться тупым дублированием event loop на всех ядрах

Дублирование event loop на всех ядрах не всегда хорошо, особенно если ядер много (16 и больше), а если их, к примеру, 4, то вполне нормально запустить 4 потока с циклом сообщений, и в них же выполнять обработку этих сообщений.

[kzv]

Код для работы с сетью в bitcoin core вполне себе асинхронный и всегда им был (раньше использовал системный вызов select, сейчас вроде как libevent, хотя на 100% не уверен), но оптимизированным его назвать сложно, т.к. он при обработке сообщения захватывает мьютекс cs_main, т.е. фактически однопоточный.

libevent это библиотека которая внутри использует тот же select или poll. Библиотека сама по себе не делает код синхронным или асинхронным, все зависит от того, кто эту библиотеку и как применяет.

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

Есть два подхода к написанию сервера, условно "как нгинкс" и "как апач".
Первый это когда после выхода из select (или poll) для каждого сокета создается отдельный контекст в главном потоке, а второй - когда каждый сокет отправляется в отдельный поток. Вот этот второй способ, он на первый взгляд кажется простым и естественным, но это только на первый взгляд. На практике, чтобы организовать межпоточное взаимодействие, придется расчехлять блокировки вроде мютексов и в результате код обретет кучу ненужных костылей, а производительность не улучшится, а скорее всего станет хуже по сравнению с асинхронным, однопоточным подходом.

[eXtremal.ik71]

libevent это библиотека которая внутри использует тот же select или poll. Библиотека сама по себе не делает код синхронным или асинхронным, все зависит от того, кто эту библиотеку и как применяет.

Не совсем так, внутри libevent использует epoll на Linux и kqueue на MacOS X/FreeBSD, отличия от select есть, и довольно заметные.
При использовании select или poll на вход этой функции передается список файловых дескрипторов, после того, как функция возвращает управление, вызывающий обязан в цикле перебрать все эти дескрипторы и проверить их состояние. Т.е. если к серверу подключены 10000 клиентов, то в ответ на приходящие данные хотя бы от одного из 10000 клиентов сервер будет проверять состояние всех 10000 подключений, алгоритмическая сложность O(n). epoll и kqueue возвращают список именно тех файловых дескрипторов, состояние которых изменилось, получаем алг.сложность O(1).
Кроме того, между select и poll есть различия, select использует номер файлового дескриптора как индекс в массиве, и если у тебя открыто более 1024 файлов (даже не сокетов, просто обычных файлов достаточно), то приложение, использующее select просто упадет.
Также надо упомянуть и винду, ее API ввода/вывода использует "порты завершения" (IOCP и чуть более оптимизированную реализация с названием RIO начиная с 8.1), поэтому libevent вынужден использовать select под виндой и не может эффективно работать.. nginx это тоже касается

Однопоточный это и есть асинхронный в моем понимании.

Ну вот опять

Есть два подхода к написанию сервера, условно "как нгинкс" и "как апач".

Апач создает новый поток на каждое подключение и захлебывается, когда количество подключений приближается к 1000 или еще раньше. Nginx использует фиксированное количество потоков (но никак не один, если это специально не указать в конфиге), которые работают в цикле сообщений, используя наиболее эффективный механизм для ОС (см. про epoll и kqueue выше).

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

Если блокироваться на мьютексе по приходу данных, как делает Bitcoin Core (да и наверное все остальные клиенты ) и отпускать блокировку по окончания обработки этих данных, то, безусловно, да А если делать по уму, и синхронизировать только передачу данных между потоками, то приложение будет масштабироваться. Если есть высокие требования к производительности, то можно внедрить lock-free контейнеры... только убедиться, что в данном конкретном случае они дают выигрыш производительности

[kzv]

Не совсем так, внутри libevent использует epoll на Linux и kqueue на MacOS X/FreeBSD, отличия от select есть, и довольно заметные.
При использовании select или poll на вход этой функции передается список файловых дескрипторов, после того, как функция возвращает управление, вызывающий обязан в цикле перебрать все эти дескрипторы и проверить их состояние.

На винде нет ни poll ни тем более epoll. Последний и не на всех линуксах есть. Так что libevent использует то, что есть в системе: select в винде, а в других - по обстоятельствам...

Nginx использует фиксированное количество потоков (но никак не один, если это специально не указать в конфиге)

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

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

Масштабироваться будет, но скорости это не прибавит, а скорее наоборот... Вот такая загогулина ))

Если есть высокие требования к производительности, то можно внедрить lock-free контейнеры...

И мы вернемся к асинхронному однопоточному приложению ))

[eXtremal.ik71]

Масштабироваться будет, но скорости это не прибавит, а скорее наоборот... Вот такая загогулина ))

Это вообще как  
Сам термин масштабирование означает увеличение производительности при увеличении мощности железа

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

nginx запускает один мастер процесс и N рабочих процессов (параметр worker_processes в конфиге), каждый из которых мониторит события на своем наборе сокетов, подключения между рабочими процессами распределяются равномерно. Да, можно сделать 1 рабочий процесс и задействовать одно ядро, а можно выставить их по количеству ядер и задействовать CPU полностью, получив при этом почти линейное масштабирование по количеству ядер, что тут может быть не понятного?
А еще можно использовать один файловый дескриптор epoll для всех подключений и опрашивать его из нескольких потоков, так получим более равномерное распределение нагрузки по потокам.

На винде нет ни poll ни тем более epoll. Последний и не на всех линуксах есть. Так что libevent использует то, что есть в системе: select в винде, а в других - по обстоятельствам...

Я же написал про винду и iocp, разве нет?
Poll есть на винде по немного другим названием WSAPoll https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll (начиная с висты)
libevent использует select, в винде  потому что использовать iocp не выйдет, другая архитектура https://en.wikipedia.org/wiki/Proactor_pattern, тут, думаю, тоже должно быть понятно.
boost asio может задействовать iocp, но он сам по себе тяжеловесный и для high load не очень рекомендуется.

И мы вернемся к асинхронному однопоточному приложению ))

Хотелось бы увидеть на примере, как lock-free контейнеры приводят к однопоточному приложению, если они предназначены для доступа на чтение/запись из нескольких потоков

[fxpc]

Масштабироваться будет, но скорости это не прибавит, а скорее наоборот... Вот такая загогулина ))

Это вообще как 
Сам термин масштабирование означает увеличение производительности при увеличении мощности железа

Не совсем верно. Термин масштабирование означает увеличение производительности при добавлении ресурсов (обычно аппаратных, но не всегда).

[kzv]

Сам термин масштабирование означает увеличение производительности при увеличении мощности железа

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

Но вы же пишете

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

Где в этой цитате что-то про железо?
Эту цитату я и комментирую при условии, что железо не трогаем.
Масштабирование это когда одну задачу можно распараллелить на любое количество потоков или процессов. В этом случае производительность может увеличиться, а может и не увеличиться. Все зависит от задачи которую распараллелили, а так же от того - как распараллелили.

nginx запускает один мастер процесс и N рабочих процессов (параметр worker_processes в конфиге), каждый из которых мониторит события на своем наборе сокетов, подключения между рабочими процессами распределяются равномерно. Да, можно сделать 1 рабочий процесс и задействовать одно ядро, а можно выставить их по количеству ядер и задействовать CPU полностью, получив при этом почти линейное масштабирование по количеству ядер, что тут может быть не понятного?

Итак зафиксируем:
1. Один поток процесс работает сразу с большим набором сокетов.
2. Можно сделать несколько потоков процессов, которые никак друг с другом не взаимодействуют. Каждый поток процесс работает независимо со своим набором сокетов.

ЗЫ: я тут на досуге документацию почитал, все таки я спрашивал про многопоточность в нгинкс, а вы переводите стрелки на процессы. Надеюсь вы в курсе, что потоки и процессы это разные вещи?

По умолчанию поддержка многопоточности выключена

Остался еще один шаг: что по вашему делает "мастер процесс"?

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

Можно... Если хотите чтобы все встало колом из-за ваших потоков и опросов

Хотелось бы увидеть на примере, как lock-free контейнеры приводят к однопоточному приложению, если они предназначены для доступа на чтение/запись из нескольких потоков

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

[Coin-1]

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

Полагаю, что разбор Вашего кода новым программистом, пусть даже "скиллованным" в области имплементации "Boost.ASIO", займёт ещё больше времени. Скорее всего, для перевода приложения на многопоточную архитектуру потребуется переписать всю Вашу программу на C++ с добавлением нового объекта "boost::asio::io_context io".

Code:

#include <boost/asio.hpp>

Честно говоря, не знаю, какие могут быть проблемы с реализацией многопоточности конкретно в Вашем случае. Документация "Boost.ASIO", описывающая использование таймеров синхронно и асинхронно, а также работу хэндлеров, в целом, ясная и понятная:
https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/tutorial.html

[eXtremal.ik71]

Не совсем верно. Термин масштабирование означает увеличение производительности при добавлении ресурсов (обычно аппаратных, но не всегда).

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

Ну тогда сортировка пузырьком тоже масштабируется...

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

ЗЫ: я тут на досуге документацию почитал, все таки я спрашивал про многопоточность в нгинкс, а вы переводите стрелки на процессы. Надеюсь вы в курсе, что потоки и процессы это разные вещи?

Это зависит от конкретной ОС, в винде это принципиально разные объекты, потоки одного процесса имеют только свой собственный контекст исполнения (регистры, стек, TLS и все что туда входит), все потоки одного процесса имеют общее адресное пространство, файловые дескрипторы, и.т.д.
В линуксе нет такой четкой границы между потоком и процессом, например 2 таких объекта могут иметь разные идентификаторы (тогда падение одного из них не затронет остальные), но работать в одном адресном пространстве, а может быть наоборот (см. параметры системного вызова clone).
Рабочие процессы в nginx в линуксе имеют отдельные идентификаторы, но предполагаю, что они имеют общее пространство файловых дескрипторов (иначе не очень понимаю, как реализивать опцию reuseport). Теперь по сути, вы называете nginx однопоточным и асинхронным, а апач синхронным многопоточным, реально же их рабочие процессы по сути одни и теже сущности в ОС (пусть будут процессы), только один рабочий процесс nginx обслуживает множество подключений одновременно, а в апаче только одно, и если nginx будет использовать классические потоки (то же самое что threads в винде), с точки зрения производительности не изменится абсолютно ничего, стабильность только пострадает.

По умолчанию поддержка многопоточности выключена (http://nginx.org/ru/docs/http/ngx_http_core_module.html#aio)

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

Остался еще один шаг: что по вашему делает "мастер процесс"?

Если говорить про сеть, то раньше он висел на приеме входящих соединений, с появлением опции reuseport это тоже переехало в worker-ы, так что теперь мастер просто читает конфиг и управляет worker-ами.

Можно... Если хотите чтобы все встало колом из-за ваших потоков и опросов

Это с каких пор epoll колом встает из-за его вызова из нескольких потоков? Может тесты какие подтверждающие есть? Это у kqueue такие проблемы есть и там рекомендуют использовать несколько независимых экземпляров для цикла сообщений, а у epoll и виндового iocp всегда все ок с этим было.

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

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

---

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