Ожидание результата в multithread приложении — кто что использует?

     

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Ожидание результата в multithread приложении — кто что использует?

    • 14,8%не использую нити в приложении вообще21
    • 22,5%нити использую, но результатами они не обмениваются32
    • 27,5%у меня есть своя заготовка с мьютексами и условными переменными39
    • 10,6%использую готовый паттерн future/promise15
    • 12,0%использую другой готовый паттерн из распространённой библиотеки (укажите, какой!)17
    • 12,7%другое18
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 38

      0
      «Результат» подразумевается в широком смысле — длительные вычисления, внешние события и т.п.
        0
        openMP делает это за меня.
          0
          А какого рода проект у вас? Много расчётов или это сервер какой?
          –1
          libdispatch делает это за меня.
            0
            Может я чего-то не понял, но где форки?
              0
              multithread-же, по этому и про IPC нету
                0
                а чем форкающееся приложение не multithread?
                  +1
                  Тем, что thread-ы выполняются внутри процесса, у них единое адресное пространство. fork(2) порождает новый процесс с отдельным адресным пространством.
                0
                fork'и попадают под пункт «другое».
                  0
                  другое обычно значит < 1%
                    0
                    Не обязательно меньше одного процента. «Другое» обычно означает нечто то, что автора голосования просто не очень интересует.
                      0
                      Меня это «другое» как раз очень интересует.
                        0
                        Не интересует довольно большой пласт исследования? Странно…
                    0
                    Может от того, что их аналог в Винде — редкостный тормоз?
                      0
                      Что есть «Винда»?
                        +4
                        А, не обращайте внимания. Всего лишь самая распространенная в мире ОС.
                          –5
                          о_О, А что такое ОС? Это такой жужжащий шмэл?
                            0
                            Да ладно вам, пятница уже началась :)
                    –2
                    Я, разрабатывая серверное приложение, использую мьютексы, ивенты, wait-функции из WinAPI и не понимаю, зачем использовать доп. библиотеки?
                      +1
                      1. чтобы не наглючить,
                      2. библиотеки, зачастую, написаны переносимо — значит, приложение может работать на разных платформах,
                      3. чтобы другой человек, читая код, сразу понимал — что, где и как используется. Одно дело — видеть распространённый паттерн, а другое — видеть очередную реализацию неизвестной работоспособности внутри.
                        –1
                        1. С библиотекой больше шансов наглючить?
                        2. Хороший аргумент.
                        3. Паттерн можно реализовать и использую функции из API.

                        P. S. Спасибо, что не написали «Зачем изобретать велосипед?».
                          +1
                          1. Нет, меньше. Чтобы вы подумали, если бы увидели в неком проекте свою собственную реализацию «динамических выделяемых объектов с подсчётом количества ссылок»?

                          3. Допустим понадобилась бы вам нить-worker, которой можно скармливать задания в runtime'е. Можно, конечно свою написать, но чем она будет лучше, к примеру, boost::asio::io_server'а или аналогов? Её ж не только написать, её же ещё отладить надо будет.
                            –1
                            3. Именно это я и реализовал (Delphi), и на с++ бы также поступил, вот правда они сильно специфические.

                            Хотя, конечно, нужно среди популярных библиотек искать готовые решения, хорошо осматривать и если подходят — принимать за основу, даже если есть небольшой проигрышь в скорости.
                              +1
                              опечатка: io_service (сервис, не сервер)
                              И таки asio на мой взгляд достаточно кривая штука, одна только реализация таймаутов чего стоит. На протяжении трех лет использовал asio в нескольких проектах, зачастую время отладки вещей связанных с сетью из-за него существенно повышалось. В более свежих версиях товарищ Колхофф вроде как сделал более человечную реализацию таймаутов, но не смотрел ее еще. По мне так лучше использовать libev/libevent какой-нибудь, грамотно обернутый. Да и работать шустрее должно.
                                0
                                Спасибо большое, чужой опыт — вещь очень ценная.
                          +1
                          Не кроссплатформенно, для серверных аппликух это особенно критично.
                          +1
                          Есть интересный подход к многопоточности в С++ в стили Эрланга.
                          Решение вполне кроссплатворменное.
                          Позволяет освободиться от объектов синхронизации во внешнем коде. Применимо в очень большом спектре задач.
                          Кого-нибудь заинтересует статья на тему?
                            +1
                            да, конечно.
                              +3
                              Зачем спрашивать заинтересует или нет. Ведь сам процесс написания статьи полезен для усваивания самого материала.
                              И даже если вы опубликуете, а никому не будет нужно, Вы же от этого не умрете, верно?
                              0
                              а boost::condition — это третий вариант?
                                0
                                Скорее, предпоследний.
                                  0
                                  либо своя либа, либо boost.
                                    0
                                    в большинстве случаев хватает грамотного использования boost::asio
                                    даже boost::condition_variable отпадает (но есть, конечно, исключения)
                                    то есть проблемы синхронизации при использовании boost::asio::io_service чаще всего не возникают.
                                      0
                                      Win32 потоки:
                                      SetEvent для Exit события + WaitForSingleObject на handle потока для ожидания его завершения

                                        0
                                        Для событий SetEvent или PostThreadMessage (PostMessage на окно)
                                        Для синхронизации Mutex
                                        иногда копирование при записи с применением lock-free алгоритмов
                                        0
                                        Использую boost::asio::io_service с возвратом результата через callback.
                                          0
                                          А что за зверь такой, этот «готовый паттерн future/promise», можно ссылку?

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое