Здравствуйте, apple-antonovka, Вы писали:

AA>>>Про OpenMP слыхали? http://www.openmp.org/drupal/node/view/11#Q1
VD>>Слыхали, слыхали. А вы слыхали о трудностях заката солнца вручную?
AA>А вы я вижу слыхали про широко используемый в рекламе прием логической привязки независимых явлений. Типа выпил СуперКолу и все бабы твои

Нет, а что хочется его применить?

OpenMP — то не автоматическое распараллеливание, а полуавтоматческое. Это конечно проще чем полный ручник, но до полноценной автоматики ему как до пикина раком. При этмо код засоряется хинтами компилятору. Что тоже не фантан.

Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.

AA>Знаю. Потому так я балуюсь исключительно для себя Зачастую это кстати дает помимо замедления еще и значительное упрощение архитектуры.

Ой сомневаюсь я на счет уерощения. Скорее усложнение. Все же не рассчитаны современные языки на параллелизм. По крайней мере "зачастую" — это явная натяжка.

VD>>Да и что в этом интересного?
AA>хз. наверно тем что такой стиль более приближен к нашей повседневной реальной жизни

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

Так что в жизни параллелизм он в осноном для разных могов, а не для одного. И при этом мозги общаются сообщениями причем для каждого из мозгов сообщения последовательны. А это как раз идея активных объектов/лайт-процессов.

VD>OpenMP — то не автоматическое распараллеливание, а полуавтоматческое. Это конечно проще чем полный ручник, но до полноценной автоматики ему как до пикина раком. При этмо код засоряется хинтами компилятору. Что тоже не фантан.
Ну OpenMP это раз. Два — это ключик /Qparallel для icl которому openmp директивы не нужны
А автоматически... полностью автоматически это пожалуй только в каком нить смоллтолке сделать можно.

VD>Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.
аналогично.

AA>>Знаю. Потому так я балуюсь исключительно для себя Зачастую это кстати дает помимо замедления еще и значительное упрощение архитектуры.
VD>Ой сомневаюсь я на счет уерощения. Скорее усложнение. Все же не рассчитаны современные языки на параллелизм. По крайней мере "зачастую" — это явная натяжка.
Очень зачастую. Просто пользоваться надо уметь
Но соглашусь что в таком стиле написанный мной код оказывается обычно проще только для меня. Причина ИМХО — не учат пока в школах/вузах многопоточному программированию толком. Рассказывают про бегинтред какой нить и мутексы в конце обучения и все. Мое мнение — программера идее параллельного исполнения взаимодействующих алгоритмов учить надо с самого начала. Тогда же когда про Чертежника/Робота там рассказывают, или что там ща в школах. В моем случае я этому научился еще в 10м классе кода на асме под спекки написал этакий шедулер потоков. А так народ и выходит из ВУЗов с плоско-функциональным мышлением в области программирования. И хорошо еще если он потом поймет хотябы как правильно юзать ООП.


VD>>>Да и что в этом интересного?
AA>>хз. наверно тем что такой стиль более приближен к нашей повседневной реальной жизни

VD>Серьезно. Ты способен одновременно делать несколько дел? Попробуй ради хохмы вертеть левой рукой по часовой стрелке, а правой ногой по часовой. Когда привыкнешь к этому попробуй на ходу поменять направление вращения. Уверяю тебя эффект будет потрясающий.
<Офтоп конечно..>
Я вижу у вас даже печатать наоборот не получилось
Между тем ногами и руками я кручу без особых проблем в разные стороны и меняюнаправление. Просто я с детства тренировался делать ассиметричные вещи левыми и правыми частями тела — тоже из интереса. От этих кручений до "перебирания" пальцами левой и правой рук в разные стороны что гораздо сложнее, но тоже получается после определенного кол-ва тренировок
</Офтоп конечно..>


VD>Так что в жизни параллелизм он в осноном для разных могов, а не для одного. И при этом мозги общаются сообщениями причем для каждого из мозгов сообщения последовательны. А это как раз идея активных объектов/лайт-процессов.
Ну я вообще не про себя конкретно говорил о жизни, а вообще о процессах в мире которые исполняются параллельно
Но это уже философия какаято....

Здравствуйте, apple-antonovka, Вы писали:

AA>В моем случае я этому научился еще в 10м классе кода на асме под спекки написал этакий шедулер потоков.

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

AA>А так народ и выходит из ВУЗов с плоско-функциональным мышлением в области программирования. И хорошо еще если он потом поймет хотябы как правильно юзать ООП.

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

Это прекрасно видно на примере FP. Пока "научившиеся ещё в 10м классе" занимались измерениями размеров своего головного мозга, толку было мало. А стоило появится нормальному инструменту с человеческим лицом и вдруг оказалось, что ничего такого волшебного в FP нет.

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, apple-antonovka, Вы писали:

AA>>В моем случае я этому научился еще в 10м классе кода на асме под спекки написал этакий шедулер потоков.

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


AA>>А так народ и выходит из ВУЗов с плоско-функциональным мышлением в области программирования. И хорошо еще если он потом поймет хотябы как правильно юзать ООП.

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


IT>Это прекрасно видно на примере FP. Пока "научившиеся ещё в 10м классе" занимались измерениями размеров своего головного мозга, толку было мало. А стоило появится нормальному инструменту с человеческим лицом и вдруг оказалось, что ничего такого волшебного в FP нет.
Хм... Три раза прочитал эту вашу фразу и так и не понял зарытого смысла

IT>Тоже самое касается и многопоточности. Проблема не в понимании как таковом. Проблема в понимании увеличивающейся на порядок сложности кода, выполняющего задачу многопоточно, по сравнению с тем же кодом, но делающем тоже самое прямолинейно.
Это отлично работает когда прямолинейно делается
printf ("hello world!");

А вот интересно как вы будете прямолинейно обрабатывать запросты в БД от одновременно 1000 юзеров? Наверное складывать в очередь и потом по очереди обрабатывывать да? Т.е. по сути самому реализовывать многопоточность, но в более понятном для вас функциональном стиле — когда все последовательно вот так сразу и работает. Переключением контекстов будет в этом случае последовательное доставание запросов из очереди вами. Данная реализация будет просто частным случаем многопоточной обработки, но синхронизированной "на корню", вместо реально нужных узких мест + вы реализуете функционал уже имеющийся в ОС. Да сейчас это по производительности выгодее, если работать на одном процессоре, но если в самом деле будут десятки ядер...

Здравствуйте, VladD2, Вы писали:


VD>В общем, факт в том что нет ни одной игрушки получающей реальное приемущество от второго камня. Хотя, сам понимаешь, по уму обязаны получать. Вопли о параллелизме были еще во времена Q2. Но воз и ныне там.


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

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


VD>Кон надо менять.

(Код?)
Ну да, разумеется. Скорости передачи данных внутри проца в разы больше, чем наружу через самые быстрые AGP. Если будут дополнительные процессоры, то даже последнюю стадию — сглаживание эффективней будет сделать внутри, чем гнать на какой-то внешний чип.

----------------------
Пофантазирую

Представим например, что мы взяли "крутой" монитор, который может отобразить 3.2k x 2.4k, возьмем 48 бит цвета, получим 46MB готовой информации на один кадр. А для работы конвеера нужны еще пара буферов для промежуточных данных, но уже с плавающей точкой, т.е. 12 байт на точку. При частоте в 100 Герц и двух паралельных конвеерах получим примерно 7.5GB вычисляемых по сложным алгоритмам данных в секунду на конвеер. Хрена себе...

Здравствуйте, Mamut, Вы писали:


> И что сможет в ближайшие пять лет?

Для .Net 7.0 ИМХО маловато будет

Здравствуйте, VladD2, Вы писали:


FDS>>Влад, что смешного? Может объяснишь...

VD>Улыбнула наивность. Уверяю тебя, что даже на 16 процессоров эффективное распараллеливание на сегодны — это очень солжная задача. А уж на 1500 просто фантастика.


Прикольно то, что на позавчера это было обыденным делом (Cray-процессоры). Грид процов, встроенная команда асемблера типа fork и всех делов. Первичным распределением ресурсов занимается аппаратура. Надо бы этот fork вводить в платформы, он гораздо удобнее и понятнее, чем объекты-треды. Ибо тред — это поток исполнения. ИМХО, потоку должен соответствовать путь исполнения кода, а не объект.


А в дотнете практически нет средств поддержки массового параллелизма (как и в Виндовс/Линукс в целом).

VD>Так что появление 80-процессорых камней неизбежно приведет к революции в средствах разрабокти. И забавно, что бывшие аутсайдеры — функциональные языки — могут оказаться очень даже в фаворе, так как неизменяемость позволяет автоматизировать распараллеливание на уровне алгоритмов. Вот только для этого еже нужно тонну работы сделать. Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.

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


VD>Человек же на таких объемах уже совсем справиться не сможет. Отдельные алгоритмы конечно можно будет распараллелить, но в целом сложность будет такая, что никто за это не возьмется.

Уже давно берутся и всю жизнь брались, но подходят немного с другого конца. Действительно, нет смысла заставлять одну операционную систему управлять всеми 1500 процессоров. Эти процы надо группировать в кластеры. У каждой ячейки кластера пусть будет несколько (немного) процессоров и собственная аппаратная память. И пусть будут мощные каналы связи (не расшаренная память, а именно каналы связи) м/у кластерами. В каждом кластере исполняется своя копия ядра ОС, а с другими кластерами общение происходит через pipes. Именно так сейчас строятся кластеры с сотнями и тысячами процессоров.

Здравствуйте, vdimas, Вы писали:

В догонку. Unix-подобная Plan9 способна работать в кластере произвольного размера, представляя кластер как единую систему с т.з. пользователя.

0xDEADBEEF wrote:
> А мораль такова, что boost::thread не предусматривает никакого
> (Никакого. НИКАКОГО!) способа убиения задачи. Ни синхронного ни
> асинхронного. So is только-что-предложенный std::thread. Следовательно,
> прибить асинхронную таску НЕ-ВОЗ-МОЖ-НО. С чем я имею вас и поздравить.
Так ведь нет НИКАКОГО общего способа нормально прибить поток.

Здравствуйте, alexeiz, Вы писали:

A>Нужны языки программирования и библиотеки, облегчающие написание многопоточного кода.
A>Могу сказать, что есть для C++. Futures обсуждаются для включения в стандарт C++. У Herb Sutter'а есть проект Concur.

Фьючерсы — это реально очень-очень крутая штука, наверно, одно из самых интересных обобщений в области ЯП. Тока ИМХО для полного счастья они должны непосредственно языком поддерживаться. Например, вот так:
http://www.ps.uni-sb.de/alice/manual/futures.html

Здравствуйте, vdimas, Вы писали:

V>В догонку. Unix-подобная Plan9 способна работать в кластере произвольного размера, представляя кластер как единую систему с т.з. пользователя.

На кластере какой архитектуры ? в том смысле как соединяются элементы кластера ? Полносвязно ? Еще как-то ?

Меня терзают смутные сомнения что на каком-нибудь хитром дереве гиперкубов это представление как единой системы будет нормально работать..

Здравствуйте, VladD2, Вы писали:


VD>А где он это говорил? И что конкретно?

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

CS>>>>Тако ж apache явно просится на такую модель. Нет?

VD>>>Ага. Только на 80 камнях он будет работать не лучше чем на 8.
AA>>Гхм. А аргументы какие? Апач активно юзает многопоточность. Те он на ней построен.

VD>Апач не может "юзать" многопоточность активнее ОС на которой он работает. А современные Видовс и Линукс 80 просто не тянут. Так что Апач даже не тисировался на подобных задачах.

Это хорошо видно здесь: Apache vs. Yaws

Apache dies at about 4,000 parallel sessions. Yaws is still functioning at over 80,000 parallel connections.

...

The problem with Apache is not related to the Apache code per se but is due to the manner in which the underlying operating system (Linux) implements concurrency. We believe that any system implemented using operating system threads and processes would exhibit similar performance. Erlang does not make use of the underlying OS's threads and processes for managing its own process pool and thus does not suffer from these limitations.

Что, конечно, не убирает проблемы:

VD> К тому же Апач это просто средство отформатировать текст и отдать по ХТТП. А вот данные что он отдает еще где-то взять нужно. И тут то и случится узкое местечко. Все клиенты ломанутся к одной СУБД и 72 процессора.

Здравствуйте, Mamut, Вы писали:

M>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?

В настоящее время подовляющее число компьютеров используется в качестве замены бумаге, ручке и калькулятору. Между тем есть такой класс задач, как моделирование. Моделировать можно всё — материалы, машины, погоду, поведение живых существ, фондовый рынок, не говоря о таких мелочах, как размещение мебели на кухне. Чем детальнее модель, чем ближе она к оригиналу, тем точнее прогноз свойств и поведения реальных объектов. Если добавить к моделированию генетические алгоритмы, то можно проектировать новые машины, отдельные их узлы не усилиями инженеров, а запустив соответствующую программу. В общем, очень перспективно.

Здравствуйте, Mirrorer, Вы писали:


V>>В догонку. Unix-подобная Plan9 способна работать в кластере произвольного размера, представляя кластер как единую систему с т.з. пользователя.

M>На кластере какой архитектуры ? в том смысле как соединяются элементы кластера ? Полносвязно ? Еще как-то ?

Кластер для Plan9 не обязан быть однородным. Да и сложновато и неэффективно все несколько тысяч ядер связать однородной связью. Могу пофантазировать: как вариант разбить на "очаги" в которых будет полносвязные соединения, а "очаги" в свою очередь — в какю-нибудь архитектуру верхнего уровня, например в звезду.

M>Меня терзают смутные сомнения что на каком-нибудь хитром дереве гиперкубов это представление как единой системы будет нормально работать..

Будет. Если м/у 2-мя процессами есть "канал", то процессы запросто работают совместно.

Здравствуйте, vdimas, Вы писали:

V> Да и сложновато и неэффективно все несколько тысяч ядер связать однородной связью.
+1 Собственно в связи с этим вопрос и возник.

V> Могу пофантазировать: как вариант разбить на "очаги" в которых будет полносвязные соединения, а "очаги" в свою очередь — в какю-нибудь архитектуру верхнего уровня, например в звезду.
Динамически???
Или руками(полуавтоматом) с перестройкой под каждую систему ?

V>Будет. Если м/у 2-мя процессами есть "канал", то процессы запросто работают совместно.
Просто Plan9 тогда должен разработать какой-то алгортим маршрутизации для передачи данными между процессами, через промежуточные.

Неужели он сам найдет оптимальный маршрут ?

Только что подумал, что в принципе можно по графу найти кратчайшие пути между всеми парами процессоров.

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

Допустим в случае однонаправленного кольца передача данных между процессами может стать реальной проблемой..

З.Ы. И что он будет делать если кусок кластера отвалится ? (Злая уборщица передавит канал связи у кольца )

Здравствуйте, apple-antonovka, Вы писали:

VD>>Это наивное мнение. Займись этим по плотнее и ты увидишь, что масштабирование SMP-систем совершенно не линейное.
AA>Линейное или нет другой вопрос. Тут скорее сказывается ограничения аппаратной архитектуры SMP, но они преодолимы. см NUMA.

Да фиг с ней, с архитектурой. А вот что делать с формулой Амдала?

Здравствуйте, Mirrorer, Вы писали:


M>Или руками(полуавтоматом) с перестройкой под каждую систему ?

имеется ввиду некая аппаратная связь, конечно же. Насчет динамической перестройки архитектуры соединений — а смысл? В иерархической модели IP-доменов хорошо живут unix-подбные системы, и Plan9 в т.ч. Да и весь сетевой софт на это заточен.

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


V>>Будет. Если м/у 2-мя процессами есть "канал", то процессы запросто работают совместно.
M>Просто Plan9 тогда должен разработать какой-то алгортим маршрутизации для передачи данными между процессами, через промежуточные.

M>Неужели он сам найдет оптимальный маршрут ?

Конечно
Статически прописать метрику на подсетки (очаги) проще простого.


M>Только что подумал, что в принципе можно по графу найти кратчайшие пути между всеми парами процессоров.

Маршрутизация встроена в ОС. Но связь каждого с каждым — это не есть важная задача. Думаю, процессам вполне можно задавать границы исполнения в рамках подсетей, и само ПО конфигурировать таким образом, чтобы наиболее общающиеся м/у собой процессы работали в рамках одного полносвязного очага.


M>Просто не может ли получиться так, что основное время система будет заниматься пересылкой данных, а не собственно задачей ?

Нет не будет. Внутри "очага" можно проложить оптические свичи м/у ядрами со скоростями в несколько MB/s. Какие основные задачи решают кластера? Моделирование погоды, расчет диффуров и моделей поведения земной коры, ядерный синтез и т.д. и т.д. Размер самих моделей обычно невелик. Велики вычисления по оной (ради чего все и затевается). Я же не думаю, что вычисления организованы так, что требуют в процессе вычисления постоянно гонять кучу данных. На примере взлома ключа шифра: каждому "очагу" был бы выделен диапазон и шифрованный текст. Обратно получилибы уже готовые данные. В общем, ничего нового. Клиент-серверные системы, а затем многоуровневые для того и появились, чтобы оптимизировать передачу данных.


M>Допустим в случае однонаправленного кольца передача данных между процессами может стать реальной проблемой..

Протоколы маршрутизации весьма успешно справляются в случае множественных путей к адресату. Кстати, откуда взялась характеристика "однонаправленный"?


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

M>З.Ы. И что он будет делать если кусок кластера отвалится ? (Злая уборщица передавит канал связи у кольца )

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

Здравствуйте, vdimas, Вы писали:


M>>Неужели он сам найдет оптимальный маршрут ?

V>Конечно
V>Статически прописать метрику на подсетки (очаги) проще простого.

Но все равно без настройки руками не обойтись, насколько я понимаю.

M>>Только что подумал, что в принципе можно по графу найти кратчайшие пути между всеми парами процессоров.

V> Думаю, процессам вполне можно задавать границы исполнения в рамках подсетей, и само ПО конфигурировать таким образом, чтобы наиболее общающиеся м/у собой процессы работали в рамках одного полносвязного очага.

Ну то есть для получения оптимального результата подкручивать что-то будет надо.
Это как раз то, что меня смущало..

V>Велики вычисления по оной (ради чего все и затевается). Я же не думаю, что вычисления организованы так, что требуют в процессе вычисления постоянно гонять кучу данных.
Представлял именно такую задачу Но это уже из области сфероконей. На практических задачах врядли такое будет, согласен.

V> Клиент-серверные системы, а затем многоуровневые для того и появились, чтобы оптимизировать передачу данных.
+1

M>>Допустим в случае однонаправленного кольца передача данных между процессами может стать реальной проблемой..

V> Кстати, откуда взялась характеристика "однонаправленный"?
Из сфероконического вакуума


V>... то, ясное дело, сетевую систему придумают максимально эффективную для организации внутренних pipes. Не уверен, что речь пойдет об IP, ибо в протоколе IP невообразимый оверхед, совершенно ненужный в случае внутричипового канала.
+1

0xDEADBEEF wrote:

> kan>Ограничение лишь из-за того, что в С++ нет поддержки ф-ций с
> переменным числом аргументов (я сказал, что нет! ).
> ...а я сказал, что нас-рать. Ибо есть overloading. И никто не мешает
> поределить функцию с одним параметром, затем — с двумя, затем — с тремя.
> Далее — насколько позволяют ресурсы, терпение и чувство меры.
> Впрочем, нашшот операторов "||" и "&&" чегой-то-там Мейерс против имел.
> Как ни странно, я с ним вполне согласен. Ибо, если я скажу "if( future1
> && future2 && non_future )" случится черт-те что с весьма неожиданными
> эффектами.
Ну вот и сделай функции
bool ready(future f1){return f1.ready();}
bool ready(future f1, future f2){return f1.ready() && f2.ready();}
и т.п.
В общем мне несовсем понятно в чём возражение (если это возражение ).

> kan>Правда с while непонятно что сделать. Правда я и не понимаю что ты
> там хочешь делать...
> "пока есть хотя бы одна 'живая' футура", вертимся.
Это практически и означает "f1.wait(); f2.wait();...". Т.е. дождаться завершения всех футур. Зачем это делать через
while/ready? Если надо что-то периодически что-то делать во время ожидания — запусти ещё один тред или timed_wait
используй. В простом случае f[n].timed_wait(timeout / totalNumberOfFutures), при необходимости более "умного" ожидания,
написано ниже.

> kan>Видимо, тебе хочется что-то типа timed_wait но чтобы таймаут был
> распределён на всех... но вроде можно обёртку написать,
> Да-а-а. Именно такое мне и хочется. Но pthread-ы (по образу и подобию
> которых смоделирован boost::thread) это не поддерживает. Делать сие "на
> коленке" тоже не выход ибо поимеешь busy-wait.
Всё просто. Имеем таймаут 10 сек и 3 футуры.
Засекаем момент времени. Ждём первую 10 секунд, когда завершается проверяем сколько времени прошло, скажем 3 секунды.
Ждём вторую 10-3=7 секунд, опять проверяем, она завершилась раньше первой, а значит ожидание затратит 0 секунд, на
третью у нас снова 7 сек есть. Третью ждём 7 сек. Т.е. просто из общего таймаута вычитать потраченное время ожидания на
каждую футуру. Если очередная футура превысит остаток таймаута — значит не дождались.
Ещё как вариант — создать ещё одну футуру, которая будет содержать "f1.wait();f2.wait();..." и вызывать timed_wait на
этой футуре.

> kan>Потом, можно соглашение сделать, что "зависать" не будет, а будет по
> таймауту отваливаться с ошибкой.
> Оки. Теперь смотрим что получается. Одна футура сдохла по исключению.
> Началась раскрутка стека "материнской" нитки. А что делать с остальными
> (еще живыми) футурами которые оказались вдруг не нужны? Способа
> корректно придушить этих "сирот рязанских" нету. Что бум делать? Душить
Один выход. Убивать себя об стену.

> их силой, рискуя уничтожить всю программу или ждать их "естественной"
> смерти (неизвестно когда), рискуя тем, что пул потоков (в конце концов)
> окажется весь оккупирован этими "сиротами" и приложение выродится
> обратно в однопоточное? Или начнем увеличивать пул и с риском
> использовать все адресное пространство и угробить всю программу куда
> более странным способом?
>
> А мораль такова, что boost::thread не предусматривает никакого
> (Никакого. НИКАКОГО!) способа убиения задачи. Ни синхронного ни
> асинхронного. So is только-что-предложенный std::thread. Следовательно,
> прибить асинхронную таску НЕ-ВОЗ-МОЖ-НО. С чем я имею вас и поздравить.
Невозможно теоретически в общем случае! И от boost/std это не зависит. Это сущность понятия thread. Иногда можно
прибивать процессы, если известно, что они не оставят какие-нибудь общие ресурсы типа файлов/базы данных/удалённого
сервиса в "неправильном" состоянии.

> kan>future не панацея для сабжа, а вполне чёткая концепция, удобная в
> определённых ситуациях.
> О! "Сей Меч позволит вам без труда победить трусливого и безоружного
> противника". Побежаль покупать. Вы за мной!
И трусливого сложно победить иногда, он может быстро бегать.

>> > Марал, до тех пор пока в C++ не будет юзабельной лямбды, futures
> уготовано место рядом с
>> > std::for_each, которым все советуют пользоваться, но никто не хочет
> kan>Мелочи реализации...
> "Дьявол — в мелочах" (с) Молот ведьм.
Тёмные века?

>> > Про требования к памяти скромно помолчим
> kan>Фигня какая, замени на auto_ptr
> Пасиб за дельный совет. А вы купите пистолет. Когда будете его
А что не устраивает-то? Или тоже задаёшься вопросом "есть ли жизнь без gc"?