Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
«Результат» подразумевается в широком смысле — длительные вычисления, внешние события и т.п.
openMP делает это за меня.
libdispatch делает это за меня.
Может я чего-то не понял, но где форки?
Я, разрабатывая серверное приложение, использую мьютексы, ивенты, wait-функции из WinAPI и не понимаю, зачем использовать доп. библиотеки?
1. чтобы не наглючить,
2. библиотеки, зачастую, написаны переносимо — значит, приложение может работать на разных платформах,
3. чтобы другой человек, читая код, сразу понимал — что, где и как используется. Одно дело — видеть распространённый паттерн, а другое — видеть очередную реализацию неизвестной работоспособности внутри.
2. библиотеки, зачастую, написаны переносимо — значит, приложение может работать на разных платформах,
3. чтобы другой человек, читая код, сразу понимал — что, где и как используется. Одно дело — видеть распространённый паттерн, а другое — видеть очередную реализацию неизвестной работоспособности внутри.
1. С библиотекой больше шансов наглючить?
2. Хороший аргумент.
3. Паттерн можно реализовать и использую функции из API.
P. S. Спасибо, что не написали «Зачем изобретать велосипед?».
2. Хороший аргумент.
3. Паттерн можно реализовать и использую функции из API.
P. S. Спасибо, что не написали «Зачем изобретать велосипед?».
1. Нет, меньше. Чтобы вы подумали, если бы увидели в неком проекте свою собственную реализацию «динамических выделяемых объектов с подсчётом количества ссылок»?
3. Допустим понадобилась бы вам нить-worker, которой можно скармливать задания в runtime'е. Можно, конечно свою написать, но чем она будет лучше, к примеру, boost::asio::io_server'а или аналогов? Её ж не только написать, её же ещё отладить надо будет.
3. Допустим понадобилась бы вам нить-worker, которой можно скармливать задания в runtime'е. Можно, конечно свою написать, но чем она будет лучше, к примеру, boost::asio::io_server'а или аналогов? Её ж не только написать, её же ещё отладить надо будет.
3. Именно это я и реализовал (Delphi), и на с++ бы также поступил, вот правда они сильно специфические.
Хотя, конечно, нужно среди популярных библиотек искать готовые решения, хорошо осматривать и если подходят — принимать за основу, даже если есть небольшой проигрышь в скорости.
Хотя, конечно, нужно среди популярных библиотек искать готовые решения, хорошо осматривать и если подходят — принимать за основу, даже если есть небольшой проигрышь в скорости.
опечатка: io_service (сервис, не сервер)
И таки asio на мой взгляд достаточно кривая штука, одна только реализация таймаутов чего стоит. На протяжении трех лет использовал asio в нескольких проектах, зачастую время отладки вещей связанных с сетью из-за него существенно повышалось. В более свежих версиях товарищ Колхофф вроде как сделал более человечную реализацию таймаутов, но не смотрел ее еще. По мне так лучше использовать libev/libevent какой-нибудь, грамотно обернутый. Да и работать шустрее должно.
И таки asio на мой взгляд достаточно кривая штука, одна только реализация таймаутов чего стоит. На протяжении трех лет использовал asio в нескольких проектах, зачастую время отладки вещей связанных с сетью из-за него существенно повышалось. В более свежих версиях товарищ Колхофф вроде как сделал более человечную реализацию таймаутов, но не смотрел ее еще. По мне так лучше использовать libev/libevent какой-нибудь, грамотно обернутый. Да и работать шустрее должно.
Не кроссплатформенно, для серверных аппликух это особенно критично.
Есть интересный подход к многопоточности в С++ в стили Эрланга.
Решение вполне кроссплатворменное.
Позволяет освободиться от объектов синхронизации во внешнем коде. Применимо в очень большом спектре задач.
Кого-нибудь заинтересует статья на тему?
Решение вполне кроссплатворменное.
Позволяет освободиться от объектов синхронизации во внешнем коде. Применимо в очень большом спектре задач.
Кого-нибудь заинтересует статья на тему?
а boost::condition — это третий вариант?
Скорее, предпоследний.
либо своя либа, либо boost.
в большинстве случаев хватает грамотного использования boost::asio
даже boost::condition_variable отпадает (но есть, конечно, исключения)
то есть проблемы синхронизации при использовании boost::asio::io_service чаще всего не возникают.
даже boost::condition_variable отпадает (но есть, конечно, исключения)
то есть проблемы синхронизации при использовании boost::asio::io_service чаще всего не возникают.
Win32 потоки:
SetEvent для Exit события + WaitForSingleObject на handle потока для ожидания его завершения
SetEvent для Exit события + WaitForSingleObject на handle потока для ожидания его завершения
Использую boost::asio::io_service с возвратом результата через callback.
А что за зверь такой, этот «готовый паттерн future/promise», можно ссылку?
en.wikipedia.org/wiki/Futures_and_promises
Одна из реализаций на С++ в библиотеке boost:
www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#thread.synchronization.futures.overview
Одна из реализаций на С++ в библиотеке boost:
www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#thread.synchronization.futures.overview
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ожидание результата в multithread приложении — кто что использует?