Добрый день уважаемые.проясните плз ситуацию.
Пишется программка. Смысл программы получение с удаленной машины в сети интернет опрделнной сруктуры данных. в 90% случаев через посредника (proxy или socks сервер(а) ) программа обрабатывает данные делает расчет и отправляет данные обратно.
1)хочется распаралелить задачу. сделать одновременно несколько запросов/ответов. как следствие возникает непонимание
что и как надо использовать. fork() или thread ?
в чем идейная разность ? как правильнее ? скажем я хочу делать 1000 одновременно работающих
вот и собственно вопрос. Детей ли ? или потоков(нитей) ?есть ли у кого примеры/ наработки/ жизн. опыт ?
Дело вкуса, уважаемый.
Хотя 1000 fork() - это немножко слишком круто.
А 1000 pthread_create() при нормальной поточной библиотеке
м приличной поддержке оных в ядре - ничего особо страшного.
>Дело вкуса, уважаемый.
>Хотя 1000 fork() - это немножко слишком круто.
Ваши слова подтверждают многочисленные записи различных уважаемых людей.
спасибо
>А 1000 pthread_create() при нормальной поточной библиотеке
>м приличной поддержке оных в ядре - ничего особо страшного.
Если к примеру мы говорим о системе freebsd, не могли бы вы подсказать, есть ли какие нибудь особенности ? ну я там слышал о ключиках при компиляции.. и прочее..
зы
СПАСИБА.
зызы
ЕЩЕ есТЬ у ДруГих МнеНиЯ ?
больше мнений нет ?
>больше мнений нет ?Какая версия FreeBSD используется?
А вообще, посмотри ссылку http://www.unobvious.com/bsd/freebsd-threads.html
Староватая, но, может чего и найдешь
Привет,Удивляюсь даже, как флеэйм не разразился... Linux или BSD, fork() или thread... :-) Вообще-то мой (скромный) опыт показал, что большой разницы в perfomance (в общем случае) не заметите. fork() несколько интуитивнее, получает копию всех исходных данных к моменту fork-a. Правда, если этих данных много, соответственно память уходит под них; зато не следует думать о синхронизации пользования данными различными thread-ами. При fork(), однако, нужно думть о wait(), когда в при thread-ах их отмирание проходит как бы более естественно. В конце концов выбор - вопрос вкуса и стартовых условий задачи (OS, портабильность, загруженость, объем данных, наличие/отсутствие сокетов и т.д.)
WWell,
>>больше мнений нет ?
>
>Какая версия FreeBSD используется?вообще ориентир 4.11
но и пятая ветка была в рассмоотрении
кроме этого в дальнейшем было желание портировать на linux
>>>больше мнений нет ?
>>
>>Какая версия FreeBSD используется?
>
>вообще ориентир 4.11
>но и пятая ветка была в рассмоотрении
>кроме этого в дальнейшем было желание портировать на linuxВ 4-й ветке libpthread НЕ использует несколько процессоров, а работает на одном, а в 5-й - полная поддержка SMP, т.е. трэды одного процесса работают на разных процах. А так, что еще - стэк для одной нити в 5-ке, если не ошибаюсь, 2 Мб. А вооще, еще ссылка:
www.kegel.com/c10k.html
>В 4-й ветке libpthread НЕ использует несколько процессоров, а работает на одном,
>а в 5-й - полная поддержка SMP, т.е. трэды одного
>процесса работают на разных процах. А так, что еще - стэк
>для одной нити в 5-ке, если не ошибаюсь, 2 Мб. А
>вооще, еще ссылка:
>www.kegel.com/c10k.html
СПА :)
ПО :-)))
>Дело вкуса, уважаемый.
>Хотя 1000 fork() - это немножко слишком круто.
>А 1000 pthread_create() при нормальной поточной библиотеке
>м приличной поддержке оных в ядре - ничего особо страшного.Ну 1000 pthread_create -- это тоже не сахар. Более того количество thread'ов на процесс ограничено. У меня в голове почему-то крутится цифра 500. Вообще, если конечно в компутере меньше сотни процессоров, лучше попробовать использовать поменьше потоков выполнения. Они ж всё равно в таблице ядрёного scheduler'а присутствовать будут, вне зависимости полноценные они процессы, или нет -- scheduler всё равно с task'ами работает. И тормозить его они будут поровну.
>Ну 1000 pthread_create -- это тоже не сахар. Более того количество
>thread'ов на процесс ограничено. У меня в голове почему-то крутится
>цифра 500.Лично мною в своё время проводились эксперименты в Linux 2.6 (+NPTL),
Solaris 2.8 и Tru64 UNIX 5.1B. Ограничивающим фактором *во всех трёх
случаях* оказался лимит оперативной памяти на процесс, так как на
стек каждого из потоков нужно место. Если оным размером стека
с умом управлять, то 10000 pthread_create() - сущие семечки. Особенно
на фоне затрат на выполнение приложением полезных функций.Естественно, что максимальную степень параллелизма с такого рода
программе лучше ограничить, например, семафором. Я последнее время
особо много thread'ов в своих программах не делаю, обхожусь пулом
потоков. Но это не всегда реально, бывают ограничения (особенно при
использовании некоторых не совсем прямых СУБД).>Вообще, если конечно в компутере меньше сотни процессоров, лучше
>попробовать использовать поменьше потоков выполнения. Они ж всё
>равно в таблице ядрёного scheduler'а присутствовать будут, вне
>зависимости полноценные они процессы, или нет -- scheduler
>всё равно с task'ами работает. И тормозить его они будут поровну.Linux-оидный взгляд на жизнь. Solaris и 100000 параллельных нитей
на одной машине тянет, и не тормозит. O(1)-планировщик тоже не
просто так придумали.