pthread_create посмотри man pthread

Спасибо !!!

.

лучше юзать родную старую добрую функцию, fork(), но это будет совсем ни как в мастдае :)))

POSIX threads & signals

Ну насчет "лучше" - это очень сомнительное утверждение. Все зависит от конкретной специфики приложения. Создание нового процесса гораздо более медленная процедура, нежели создание нити. Если новые ветви программы создаются часто, лучше использовать threads.

> Создание нового процесса гораздо более медленная процедура, нежели создание нити.
Сам проверял :)? Или "наслушался" ?


IMHO все зависит от того, насколько "новые ветви программы создаются часто". Если
десятки /тысячи раз в секунду, то надо threads юзать. Или (как правило, предпочтительнее)
логику программы пересмотреть.

fork IMHO значительно удобнее / надежнее.

bison в Linux'е нет нитей есть только thread'ы а нити реализованы как thread'ы с общей памятью (см. clone() и если не ошибаюсь glibc так как pthread_... реализована именно там.)

Ну да fork удобнее:) - думай как данный гонять между процессами, shared memory синхронизация, etc Сплошное мучение.

С нитями правде не намного легче - блокировки, опять же синхронизация. Но нити действительно работают быстрее:)) Сам проверял и 2.2.Х и в 2.4.Х :))) В 2.4.Х порождение нитей на порядок быстрее нежели процесса (у меня получалось в 10 раз при малой загрузке и в 6-7 раз при сильной) :))

А в действительности - для каждой задачи свое решение, иногда нити иногда процессы.

TO anonymous (*) (2001-12-27 10:59:19.0): Thread = нить, а нити или threads действительно реализованы by clone, а pthread - всего навсего билиотека над clone с реализацией поведения требуемого в POSIX.

Нити ВСЕГДА используют общую память процесса :)) на то они и нити:)) + имеют свой собственный стек:))

Good luck!!!

POSIX threads & signals

Друзья мои! Да, мы находимся в форуме LINUX.org.ru. И все же не стоит забывать, что кроме Linux существует еще много операционных систем, хороших и разных :). Я, к примеру, работаю под FreeBSD.

To: Die-Hard >> Создание нового процесса гораздо более медленная процедура, нежели создание нити. >Сам проверял :)? Или "наслушался" ?

Честно говоря, я не вижу ничего плохого в том, что я стараюсь читать документацию перед тем, как использовать ту или иную возможность библиотеки... Вообще, по определению fork() рано или поздно должен скопировать контекст процесса (я имею в виду copy-on-write), тогда как при использовании pthread_create() этого не нужно. Опять же по определению - thread = __lightweight__ process. И с чего бы это он так назывался, а? :) И еще вопросик - зачем, интересно, по-твоему, Apache2 (например) на thread'ах пишут? Мода, наверное нынче на них, не иначе...

To: anonymous Вообще-то "нить" это и есть наиболее частый перевод слова "thread"...

ЗЫ С удовольствием с вами поспорю, если я неправ, но все-таки хочется, чтобы помидоры летели конструктивные :)

2bison (*) (2001-12-27 13:26:30.0):
> И еще вопросик - зачем, интересно, по-твоему, Apache2 (например) на thread'ах пишут?
> Мода, наверное нынче на них, не иначе...
Точно! Мода диктует, порой, совершенно чудовищные с точки зрения здравого смысла решения...

Вообще, я согласен, что нитки стартуют быстрее полновесного процесса.
Просто по определению, тут ты прав.

Но только - насколько часто это действительно критично? IMHO - только для SMP
specific фенечек. WEB сервер, кстати, сюда подходит, так что разработчиков Апача
я тоже понимаю, как раз тот самый редкий случай, когда нитки предпочтительнее.

> ЗЫ С удовольствием с вами поспорю, если я неправ, но все-таки хочется, чтобы помидоры
> летели конструктивные :)
Знаешь, подобные дискуссии разгораются тут каждый месяц. Только недавно
мы с Havoc'ом спорили до хрипоты - один хрен, почти при своих остались.
Собственно, мне просто нечего добавить - я ж не магнитофон, все время
одно и то же повторять!

Ежели чего нового отпишешь - поддержу тему...

POSIX threads & signals

Да не, добавить нечего. Ну не страшно, не на эту тему, так на какую другую еще поспорим ;)

Это лучше, чем линукс vs other :)

Честно говоря, немного жаль, что чуть-чуть опоздал к раздаче помидоров;)
но все ж таки высказаться хочется, аж заснуть не могу;)

суть в том, что фраза "thread == Light Weight Process (LWP)" - более, чем спорна.

немного теории:
на жирных коммерческих *nix платформах уже давно библиотека pthread представляет проецирование из user-thread в kernel-thread по следующим трем схемам: N:1, 1:1, N:M, которые задаются в policy scheduler'a из библиотеки pthread.

см. маны по
pthread_attr_setinheritsched();
pthread_attr_getinheritsched();
pthread_attr_setschedpolicy();
pthread_attr_getschedpolicy();
pthread_attr_setschedparam();
pthread_attr_getschedparam();

другими словами, библиотека pthread фактически представляет собой виртуальную машину, которая обеспечивает переключение user-thread'ов даже без перехода в kernel-mode. т.е. не происходит перехода между user и kernel режимами, что и экономит время.
таким образом, LWP - это скорее ссылка на kernel-thread, т.к. он более "реален", чем user-thread, который работает в виртуальной машине библиотеки pthread.

что касается Linux, то, по всей видимости, не за горами то время, когда он тоже будет обеспечивать три схемы (N:1, 1:1, N:M) диспетчеризации user-thread'ов, как и другие, более "устоявшиеся" старшие его собратья;)

p.s. очень хорошо схема диспетчеризации user-thread'ов в библиотеке pthread описана в доке по IBM AIX. вот только жаль ссылку на pdf-ник не помню;)

Не соглашусь с Die-Hard по поводу моды на thread'ы. Это скорее не мода, а суровая необходимость использовать преимущества, которые можно вынести из диспетчеризации user-thread'ов без перехода в kernel-mode. Другими словами, исходя, например, из схемы диспетчеризации 3:2 (M:N), то на 3 user-thread'a приходится 2 kernel-thread'a. И при этом работают 2 scheduler'a: один непосредственно в kernel, а другой в библиотеке pthread. Таким образом, чем больше в системе процессоров, тем равномернее получается их загрузка, т.к. над решением этой проблемы трудятся уже 2 scheduler'a, каждый со своей стороны.