Linux быстрее в создании процессов и потоков(нитей)

2Antichrist (*) (2002-02-18 00:41:34.0):
> По поводу сериализации - фишка в том и заключается, что в случае с тредами
> её не надо, и делается она только если получатель сообщения живёт в другом
> процессе.
Я бы понял, если б ты сказал "если получатель сообщения живёт в другом
узле кластера". Зачем нужна сериализация, если можно расшарить процессам
"почтовую" память?

> Ну а вообще, треды меня интересуют в первую очередь с точки зрения
> SMP-параллелизма.
Мы же сейчас про пул говорим, а не просто про треды.
Antichrist (*) (2002-02-18 00:46:48.0):
> На фиг нужен пул из тысячи тредов? Обычно на параллельное исполнение имеет
> смысл посылать не более десятка обработчиков, или не более N тяжёлых
> процесорожрущих обработчиков, где N - число процессоров.
Ты про SMP говоришь. А я как раз иначе себе представлял бенефит, получеамый
от юзания пула.

Для получения высокой peak performance у веб сервера, например, такая очередь
будет демпфировать пики. Если пиков мало, но они большие, то размер очереди
может требоваться немалый. Поэтому я и писАл про тысячи.

Впрочем, немного поразмыслив, я начинаю понимать, что не прав.

Если, допустим, все происходит на одном процессоре, то к уменьшению latency
такая очередь не приведет. Более того, средняя производительность упадет.
Ситуация похожа на обсуждавшуюся в связи с preemptible kernel.
Т.е. подобная конструкция могла бы быть полезной в весьма специфическое
ситуации, когда в момент прохождения пиков требуется иногда обрабатывать
высокоприоритетные запросы, нечто вроде real-time WEB server :-).

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

Нитки заместо процессов юзать надо лишь по одной причине - так проще. Нет никаких заморочек с SHM, более эффективные мутексы. Ну и главное - для меня - то, что ВСЯ память шаренная, и при этом сборка мусора корректно работает. Как её заставить работать в случае с shm и процессами - не имею понятия.

2Antichrist (*) (2002-02-18 16:59:03.0):
Нитки vs. процессы мне сейчас влом собачиться. Видимо, это, типа, религия.

А вот что крайне интересует:
> более эффективные мутексы.

Почему?
Я думал, мутексы на семафорах построены, просто врапперы к семафорам.
А семафорам совершенно все равно, кто на них спит.

Кстати в той программе мерялся не скорость создания потоков, а скорость создания и удаления потоков. А это не одно и тоже.

anonymous:
Я профайлил это программку. Создание трэда занимало примерно 65 % времени, ожидание его завершения и очистка хэндла - 33%

Die-Hard:
Each new thread receives its own stack space, consisting of both committed and reserved memory. The system will commit one page blocks from the reserved stack memory as needed, until the stack cannot grow any farther.
Подробнее не скажу, но я помню, что впервые про это прочел в доках к 386-му процессору.

>Или контроль стека реализУем каким-нибудь хитрым механизмом, типа
>pagefaults?

Именно так. Это фича 386-го проца.
Есть спецдескрипторы, которые могут динамически расширяться вверх или вниз. Расширение вниз используют для стеков.

>Проблема в том, что она не будет освобождаться. Т.е., весь пул будет
>быстро распухать до размеров (самый толстый коллбэк)*(кол-во тредов)

Ну разбухнет. СУБД ведь забирают память, а потом хрен отдают.

нашли с чем сравнивать... ето типа AMD vs Intel.... все равно никакого толку, что сравнивай , что не сравнивай, из-за этого ни один Виндовсист не перейдет на линух, так что в итоге мы опять , как всегда, получили синтетический тест, который ничего не решает

2Havoc (*) (2002-02-19 12:00:41.0):

> Ну разбухнет. СУБД ведь забирают память, а потом хрен отдают.
Я хотел их тысячами гонять, соблазнившись тем, что они ресурсов не едят.

Все, я уже все понял, так делать не надо.

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

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

Похоже Die-Hard думал несколько об другом. Такой подход пользуется практически везде. В ряде программ потоки специализуруются (ГУИ, звук , етц) (XMMS, balsa, etc). В ряде имеется фиксированного размера пул. И это правильно. Такой подход применяется для всякого рода серверов. В этом случае потоки нужны для поддержки SMP. Других причин нет. Т.е. потоков должно быть немного больше чем процессоров.

Если вам важно время переключения между потоками, то лучшее решение --- userspace потоки. Обратите внимание на pthreadsNG от ИБМО.

Да, товарищ Ленин сказал бред. Память под стек действительно резервируется (linux threads выделяет 2метра по умолчанию). В POSIX (который и реализует linux threads) этот параметр конфигурируется. Но память на стек на любой платформе резервировать необходимо если threads там --- threads (то есть общее адресное пространство)( это легко понять если слегка напрячь /dev/brains) . Я далеко не спец Вынь32, но если там жестко 1метрабайт/тред, то это маленький минус для этого АПИ.

Отсюда вывод --- неправильно немерянно жрать стек (не хип!) в многопоточных программах. Если это все таки надо --- пользуйте fork+SHM.

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

Алексей