LINUX.ORG.RU

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


0

0

www.linux.org.ru
"Linux быстрее в создании процессов и потоков(нитей)
Тест производительности создания потоков.
Участники:
Linux RedHat 7.2 (ядро 2.4.2)
Windows XP
Windows 2000
http://www-106.ibm.com/developerworks/linux/library/l-rt7/";

Поясните плз, кто в системном программировании силен. Как такое может
быть?
Ведь изначально в юниксе вообще не было потоков(не задумывался он
изначально для серьезных дел, - проектировался фактически как офисная
система, для печати, хранения файлов,...),
и вся многозадачность сводилась к порождению процессов вилкой (fork).
Да и сейчас потоки не используют практически, уж не
знаю кривость их реализации виновата или традиции так сказать.
Достаточно запустить ps -ef и можно увидеть кучу процессов
где в NT обычно используются потоки.

http://www.citforum.ru/operating_systems/articles/process.shtml

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

Как мы видим, практически в линуксе нет потоков вообще, а есть некий
врапер,оболочка для их (POSIX) эмуляции.
Т.е. как, фактически порождение процесса, может быть быстрее
порождения реального потока (в том же адресном пространстве)?

P.S. я не хочу подымать флейм, можно и без потоков жить(с Ораклом
так удобней даже админу),но вот разобраться бы хотелось.
Вообщем, хотел сказать, - не пинайте сильно.





Ответы на вопросы, которые ты задал, если на них отвечать в стиле "чтобы было понятно многим", могут занять место в несколько раз больше, чем статья на CIT Forum, которую ты привел как первоисточник.

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

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

Я работал с данной библиотекой на платформах Solaris, HPUX, AIX и Tru64 и на каждой есть своя реализация. В Linux'е, насколько я понимаю, существует своя. Сравнивать ее с реализацией на других платформах в таком виде, как это проделано в статье - не корректно.

Поэтому, твой вопрос в общем виде поставлен некорректно, а следовательно, дать корректный ответ на некорректный вопрос, - представляется крайне затруднительным.

Суть некорректности твоего вопроса в том, что ты не совсем разобрался в механизме Thread'ов, до конца не осознал, для чего они были созданы и в чем их назначение.

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

proff
()

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

Так в твоем случае с процессами.
Что такое другое адресное пространство по твоему?
Другой мир? Абсолютная независимость?

Нет, это ошибка, т.к. это всего лишь программная абстракция, потому что память она одна и называется она - физической. ;-)

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

Теперь прикидываем: каталог таблиц страниц занимает одну страницу (допустим это 4К) и таблица страниц занимает одну страницу (это еще 4К) и этот несчастный регистр, который в некоторых клонах (например в SCO'тине) вообще не изменяет своего содержания.

И вот теперь подумай, разве сложно отработать эти несчастные 8К при создании процесса? И насколько это критично при создании?

p.s.

1. К слову о птичках: помимо frok() есть еще так называемый виртуальный fork - vfork(). Но о нем, для особо страждущих по отдельному запросу;)
2. Оставил без внимания вопиющий инцидент, фразу "Ведь изначально в юниксе вообще не было потоков (не задумывался он изначально для серьезных дел...)". Думаю по поводу этого можно пофлеймить страницы на четыре, а то и поболе;) Ща, только Антихрист подгребет;)
3. Для тех, кто не понял ответа: буквально на вопрос не отвечал, но мне показалось, что прочитав это, можно ответить на него себе самому.

proff
()

Mozilla Mail

proff (*) (2002-02-16 01:41:50.0)

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


>>2. Оставил без внимания вопиющий инцидент, фразу "Ведь изначально в
>>юниксе вообще не было потоков (не задумывался он изначально для
>>серьезных дел...)".
>Думаю по поводу этого можно пофлеймить страницы на четыре, а то и поболе;)
>Ща, только Антихрист подгребет;)
Это что за нечисть такая(я тут новенький)? Впрочем ты прав, лучше этот тред
не засорять флеймом о том кто лучше, армяне или грузины -все хороши!
Но вряд ли кто-то будет спорить, что UNIX затачивался изначально
для работы к примеру с СУБД - тогда (1969) все серьезные СУБД (и другие
серьезные задачи) жили на мэйнфрэймах, все-таки юникс делали
прежде всего для тех задач, которые сейчас зовут офисными -
печать, разделение файлов, почта, обучениие. Сейчас конечно все поменялось
и к примеру, для Оракла юникс это главная платформа.





Lem_I
() автор топика

Quake3

>Я работал с данной библиотекой на платформах Solaris, HPUX, AIX и Tru64 и на
>каждой есть своя реализация. В Linux'е, насколько я понимаю, существует своя.
>Сравнивать ее с реализацией на других платформах в таком виде, как это
>проделано в статье - не корректно.
Собственно я не покушался (да и автор статьи вроде ТОЛЬКО о линуксе
говорил) на другие платформы( у Tru64 вообще ядро интересное),
был приведен отрывок из статьи

http://www.citforum.ru/operating_systems/articles/process.shtml

показывающий, что фактически в линуксе НЕТ потоков
ВООБЩЕ(с точки зрения
ядра). Что это замаскированные процессы с флагом CLONE_VM.
Если бы вы опровергли эту информацию, то это было бы к теме.
И это было сделано к статье, ссылка на которую, была помещена на linux.org.ora

http://www-106.ibm.com/developerworks/linux/library/l-rt7/";;

о крутости линуксоидных потоков по-сравнению с NT'ёвыми.

Еще раз повторюсь, мы обсуждаем статью
http://www-106.ibm.com/developerworks/linux/library/l-rt7/";;


>Поэтому, твой вопрос в общем виде поставлен некорректно, а следовательно,
>дать корректный ответ на некорректный вопрос, - представляется крайне
>затруднительным.

Уточню вопрос, ход мысли такой:
1. Процессы по определению(графики посмотрите) порождаются дольше потоков
(согласен с рассуждениями о адресном пространстве, но потоки
порождаются быстрее на порядок, может быть и отчасти потому, что они
используют тоже адр. пространство и поэтому им не надо создавать
КОНТЕКСТ процесса, впрочем ты это лучше объяснишь я надеюсь, и жду:))

2. Раз в ЛИНУКСЕ фактически потоки являются процессами, то как они могут
запускаться быстрее?

Или одним вопросом -
Почему в линуксе потоки создаются намного быстрее процессов, если они
(потоки) являются процессами(в линуксе)?
Речь даже не идет о NT'евых потоках.

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










Lem_I
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.