Войти
ПрограммированиеФорумОбщее

Модели многопоточности, или "Прощайте дедлоки" (комментарии)

Страницы: 1 2 3 Следующая »
#0
12:49, 25 дек. 2011

Модели многопоточности, или "Прощайте дедлоки" (комментарии)

Это сообщение сгенерировано автоматически.


#1
12:49, 25 дек. 2011

>"Обещания результатов" (futures, promises). Примеры такого подхода могут быть найдены в С++ (библиотека ASIO, Boost.Asio)
>Boost.Asio
Boost.Asio же библиотека межсетевого взаимодействия.  Откуда там (futures, promises)?
Зато в Boost.Thread они есть.

>Лично рекомендую библиотеку ZeroMQ
Было бы неплохо расписать её конкурентов и почему они были отброшены. Или хотя бы расскажите почему выбрали именно эту библиотеку?

#2
13:17, 25 дек. 2011

Таки в Erlang тоже бывают дедлоки.

#3
15:07, 25 дек. 2011

Конишуа
> Таки в Erlang тоже бывают дедлоки.
Можно поподробнее? не встречал.
Как воспроизвести?

#4
15:48, 25 дек. 2011

Читал это когда-то не очень давно, и многое показалось мне или демагогией, или настолько плохо разъяснено, что кажется демагогией. Все методы, кроме первого, рассматриваются как альтернатива "общей памяти и локам". Читаем:

Процессы содержат своё состояние в себе, и общаются друг с другом только посредством сообщений, которые не хранятся в общей памяти, а копируются от процесса к процессу, и ложатся в специальный, личный для этого процесса, "почтовый ящик". Такая коммуникация является полностью асинхронной, никто никого не ожидает и сообщения обрабатываются другими процессами по мере возможности, когда удобно им. Более сложные модели коммуникации могут быть построены на этом примитиве. Такая модель совместной работы иногда ещё называется Actor Model.

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

Звучит складно, пока не начинаем задумываться. Например, об вот этой самой "специальной бесплатной службе", которая является... не ещё ли одним процессом, вполне себе полноценным, и через это отнюдь не бесплатным? И об "специальном, личном для этого процесса, "почтовом ящике"", который является... постойте-ка... не общей ли памятью для "'этого процесса" и "специальной бесплатной службы"? Которую, для корректного совместного доступа процесса и СБС, не лочить ли надо? Простите, а в чём же тогда альтернативность?

#5
15:52, 25 дек. 2011

> а в чём же тогда альтернативность?
Само лочит. Когда надо и когда не надо.

#6
15:56, 25 дек. 2011

Sbtrn. Devil
Это скедьюлер называется (scheduler) - отдельные системные треды по 1-2 на ядро процессора, которые занимаются доставкой сообщений. Сообщения по возможности лишний раз не копируются, просто перебрасывается указатель из ящика в ящик. Да, на самом деле он не бесплатный, оверхед есть, но ради 1 млн одновременно подключенных клиентов, и это, заметьте в честных софтовых тредах, эмулируемых эрлангом, каждый со своим стеком, и каждый может уйти в sleep или заблокироваться по read, я готов это терпеть ;)

#7
18:52, 25 дек. 2011

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

А вот расскажите мне, посоны - кто-нибудь делал task-based многопоточность?
Кто именно и когда создаёт таски?
Как определяется на какой поток какие таски кидать?
Как вычисляется приоритет тасков?

#8
21:31, 25 дек. 2011

>И об "специальном, личном для этого процесса, "почтовом ящике"", который является... постойте-ка... не общей ли памятью для "'этого процесса" и "специальной бесплатной службы"? Которую, для корректного совместного доступа процесса и СБС, не лочить ли надо? Простите, а в чём же тогда альтернативность?
Альтернативность в том, что в этот лок не долбятся 100500 тредов. При этом на очередь сообщений у тебя ровно 1 reader и 1 writer. С таким раскладом можно сделать lock-free и практически wait-free (тупо double buffer прокатит).

#9
22:08, 25 дек. 2011

Mr F
> кто-нибудь делал task-based многопоточность?
Делал.
Главный тред создает задачи. Пишет их каждому рабочему треду, пока тот спит, в их task description, а затем делает кадому треду с заданием wake up.
Как только работник проснулся, он тут же сбрасывает закрепленный за ним сигнал готовности. Как только тред выполнил работу, он пишет данные в task result, и опять засыпает.
Главный тред, перед раздачей новых тасков, может вести себя по разному. У меня например просто ждал пока все потоки, запущенные, скажут, что они готовы.

#10
22:39, 25 дек. 2011

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

#11
23:01, 25 дек. 2011

laMer007
> > Обещания результатов" (futures, promises). Примеры такого подхода могут быть
> > найдены в С++ (библиотека ASIO, Boost.Asio)
> >Boost.Asio
> Boost.Asio же библиотека межсетевого взаимодействия. Откуда там (futures,
> promises)?
> Зато в Boost.Thread они есть.
А я даже покажу.

boost::asio::async_write(*connection.socket(), buf.data(),
    boost::bind(&SpikingMatrixClient::onAddMatrix, this, boost::asio::placeholders::error,
        boost::asio::placeholders::bytes_transferred));
Когда ты стартуешь таймер или операцию какую-то, ты ему передаёшь колбек. Вот фактически это и есть future, по нему через некоторое время тебе гарантируют прислать либо ошибку либо результат. Пока колбек не сработает, дальше логика программы не продвинется. Это архитектура data flow.
Но поскольку ASIO дофига умная, там есть и другие способы, многопоточный сокет реактор, например.
#12
2:02, 26 дек. 2011

Wraith
> Альтернативность в том, что в этот лок не долбятся 100500 тредов. При этом на
> очередь сообщений у тебя ровно 1 reader и 1 writer.
Оно как бы да, но. Поскольку "служба почтовой доставки" одна, то перед тем, как добраться до ящика 100500-го потока и взять его запрос/доставить ему ответ, она должна будет залочить-разлочить (последовательно) ящики предыдущих 100499 потоков. Конечно, пославший сообщение процесс теперь физически не блокируется до ожидания ответа и сделать ещё что-то. Но для продолжения работы именно ответ-то процессу чаще всего и нужен. То есть, вместо физического блока мы получаем логический, аналогичный по сути и времени простоя.
Нечто похожее на профит будет только в том случае, если процесс сильнопараллельный - за один присест отсылает массу независимых друг от друга запросов и потом дожидается массы же ответов. Такому процессу да, будет в какой-то мере профитно (и то...). Но это задача слишком явной специфики, типа сервера или маршрутизатора. Её профит будет за счёт соответствующего пенальти клиентам, занимающимся более прикладными алгоритмами.

#13
2:46, 26 дек. 2011

Mr F
> значит у тебя есть главный тред, который постоянно флажок свободности у других
> потоков?
> или этот раздатчик является сам по себе частью одного из воркер-тредов?
В главном потоке все обрабатывается. Поток только для формирования и отсылки задач, мне показался тогда лишним. Ибо кто то же должен будет сообщать треду планировщику эти задачи. Т.е. по сути не нужная вставка.

#14
6:30, 26 дек. 2011

>Оно как бы да, но. Поскольку "служба почтовой доставки" одна, то перед тем, как добраться до ящика 100500-го потока и взять его запрос/доставить ему ответ, она должна будет залочить-разлочить (последовательно) ящики предыдущих 100499 потоков.
Вот непонятно почему это последовательно. Ну т.е. я никаких ограничений не вижу.

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

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.