Народ вот скажите, я компалю свою прогу на threads'ах. В проге 4 нитки. С Linuxthreads через ps вижу все 4 отдельно. А когда скомпайлено с NGPT вижу только один процесс. Кто подскажет к чему бы это? Машинка на одном cpu.

В линуксе каждый thread имеет свой pid != POSIX

2 anonimous : Все правильно - так оптимальнее. Типа ngpt заводит новые clone процессы только тогда , когда это надо. Типа в нескольких линуксовых процессах могут крутится дофига тредов. Оверхед сильно снижается - и в этом главный рулез. Для одного процессора модель один процесс <- много тредов гораздо выгоднее. А вот если процессоров несколько - ngpt запускает несколько разных процессов что-бы ядро могло запускать их на разных прцессорах. В таком случая, насколько я понимаю, количество процессов = кол-ву активных нитей. Типа если нить чего-то ждет - то на нее нет линуксового процесса.

2 MrBool: не в "линуксе", а в LinuxThreads

2 kernel: при правильной реализации оверхед действительно снижается, однако в ngpt-1.2 с этим были определенные проблемы... Главная, с которой столкнулся я - не удалось избежать блокировки _всего_ процесса на различных сисколлах, и при soft syscall mapping, и при hard syscall mapping тоже :(

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

А все в среднем уже сейчас NGPT дает прирост производительности если я например mysql с ним слинкую?

С тормозами научился кто-то бороться

Я тут обнарудил одну очень не приятную особенность NGPT - если в одной из ниток на однопроцессорной машинке закрутить бесконечный цикл другие нити тоже выполнятся не будут.

Кто нибудь научился с этим делом бороться ?

2 anonymous (*) (2002-05-18 14:42:47.082): попробуй, но я бы не советовал ;)

2 PeterZ: С этим нельзя бороться, потому что многозадачность в NGPT не вытесняющая, т.е. нет понятия кванта времени. Управление другим потокам передается при вызове сисколлов в основном. Цикл типа:

for (long i=0;;i++) {}

гарантированно подвесит весь процесс. Кстати, советую почитать про то, как устроены NGPT и GNU Portable Threads, там все написано.

ЗЫ: успехов с MySQL ;)

Кст, вот так виснуть ничего не будет:
for (long i=0;;i++) { sched_yield (); }

Самое обидное в той же Windows NT/2000/XP вот такая вот хрень
for (long i=0;;i++) {}
пущенная в одном из тредов остальные не заблокирует.
В Win32 вытесняющая многозадачность актуальна и для тредов.
А для люителей самостоятельно управлять вытеснением потоков имеются fibres.

Вот только не надо сразу про виндоус, ладно? В LinuxThreads это также не вызовет блокировки процесса, а NGPT - это не "линукс", это одна из сторонних библиотек, к тому же не дописанная.

Заблокирует.
Более того. Это процесс съест 99% ресурсов.

Мой предыдущий постинг про Виндовс.

да фигня... вот посмотрите на FreeBSD 5.0 с её KSE и ваще - вот там это да, это будут треды, и SMP и ваще :))))))))

>> Заблокирует.
>> Более того. Это процесс съест 99% ресурсов.
Не заблокирует. Остальные потоки БУДУТ выполняться.
А если приоритет этому (с бесконечным циклом) понизить - так вообще незаметно будет что он в этом цикле крутится. Процессор конечно будет 100% занят.
Но работать все будет.

Спорим на ящик пива. ;)))

>> Заблокирует.
>> Более того. Это процесс съест 99% ресурсов.
Не заблокирует. Остальные потоки БУДУТ выполняться.
А если приоритет этому (с бесконечным циклом) понизить - так вообще незаметно будет что он в этом цикле крутится. Процессор конечно будет 100% занят.
Но работать все будет.

Спорим на ящик пива. ;)))

АХТУНГ! Не надо про FreeBSD. Щаз придёт анонимус, у которого NGPT 314дато работают, и всё зафлеймит...

to (bull)Sh**
Он уже пришел, и (пока) мягко так предупреждает всяких теневых убраться с поля
по добру по здорову ;)

>> Заблокирует.
>> Более того. Это процесс съест 99% ресурсов.
> Не заблокирует. Остальные потоки БУДУТ выполняться.
> А если приоритет этому (с бесконечным циклом) понизить -
> так вообще незаметно будет что он в этом цикле крутится.
>Процессор конечно будет 100% занят.
>Но работать все будет.

Похоже ты прав, а я нет.

> Спорим на ящик пива. ;)))


Неа. ;)

Хм..
Если NGPT не вытесняющие значит в этом есть смысл. То что я вычитал это большой прюс при переносимости. А что еще? А какие минусы?
Циклы не катят за минус, так как зная что NGPT не вытесняющие надо писать по другому.

Я так понял NGPT готовят к 2.5 ядру. Как оно там будет жить с вытесняющим ядром? И кто что думает NGPT когда-нибудь заменит LinuxThreads или навсегда останется LinuxThreads?

Последний анонимус: Какой может быть плюс при не вытесняющей много задачности? Это примерно так же как сказать, что Windows 3.1 (где была не вытесняющая многозадачность) лучше для переносимости (переносимости куда?).

> Если NGPT не вытесняющие значит в этом есть смысл.
Простота реализации, больще смысла нет.

> Я так понял NGPT готовят к 2.5 ядру. Как оно там будет жить с
> вытесняющим ядром?
А как вытесняющее ядро соотносится с userland NGPT?

К сожалению если ребята в NGPT не подправят вопрос многозадачности то это пакет мертворожденый - плюс от них тогда по сравнению с обычными User Level потоками только поддержка SMP... Я то надеялся что они их побольше с Solaris слижут.

Реально невытисняющая многозадачность означает не больше не меньше что с текущими приложения ее использовать будет нельзя так как никто в циклах явно через две инструкции шедулинг не ставит.

MySQL один тому пример. Apache 2.0 еще один. Да кучу приложений можно закрутить так что на несколько секунд будет что-то вроде цикла...

Я вот нашел тот же вопрос и ответ в рассылках. В общем они работают и глядишь все будет
We're currently working on method that we allow us to do fully
preemptive scheduling but it's not yet ready for prime time.

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

У меня squid c pthread не захотел перловый редиректор запустить

У меня squid c pthread не захотел перловый редиректор запустить

какой десктопный софт пользует pthread?

Opera использует pthread

Что то я не понял насчет приближения к Solaris и IRIX.
В IRIX все по уму - все вытесняется и без syscall.
Так что не мутите разум. А в Solaris вообще несколько типов
mt поддержки есть.
Текущая реализация pthread в Linux идеальна для аппликации и
немного напряжна для ядра. А эту херню NGPT помоему начали писать
только для того что бы "свой след в истории оставить".
Windows 3.X народ не юзал так что решили на своей шкуре
исследовать как не вытесняющая "многозадачность" работает.

Работает пока не идеально, но разница в скорости очень солидна.
Для mysql на отдельных тестах - 2-3 раза. Так что ngpt заслуживает внимания.

>Для mysql на отдельных тестах - 2-3 раза.

очень интересно. На каких тестах? Как измерял? Как прикручивал это к mysql?

Я тоже как-то прикручивал к mysql. mysql дибильным методом провыряет чтобы на линухе был Linuxthreads, делает cat pthread.h | grep Linuxthreads | wc
и чтобы mysql не почуял замену достаточно воткнуть в файл include/pthread.h строчку с Linuxthreads

Все анонимусам : Все с этим проектом будет в порядке. Вы на список специалистов core team смотрели? Cплошь IBM и Intel. Естественно что это один из сложных проектов - если-бы треды n в m было бы просто - давно бы уже сделали. Как мне кажется это как раз то, на что идет миллиард от IBM :-). Более того, как мне кажется, раньше 2.5 этого ждать не стоит. Это действительно СЛОЖНО.

В последних 2.4.19-pre уже присутствует вся инфраструктура для ngpt.
Бери, компиляй, заменяй phreads и тестируй. Никакой сложности.

> На каких тестах? Как измерял? Как прикручивал это к mysql?
mysql_home/tests/fork_big.pl. Измерялось время исполнения с растущим числом клиентов.
Чем их больше, тем выше эффективность ngpt.
Прикручивается элементарно. Нужно установить ngpt как в доках написано и иметь
mysqld собранный с динамическими библиотеками, т.е. бинарник с сайта mysql не подойдет.

> mysql_home/tests/fork_big.pl.

А что сказали тесты mysql-test ? все passed? mysql от этого дефективным не стал?

Да, вытесняющая многозадачность нужна. Но надо заметить что проблему с переключением нитей в середине вычислительного цикла она не решает. Пример тому нити на Солярисе. Да и не нужно ее решать ибо это псевдопроблема (на самом деле такое поведение практически никогда и не нужно). Решается эта проблема наличием time-slicing.

> mysql от этого дефективным не стал?
Стал. Далеко не все тесты проходили, но я тестировал старую версию ngpt 1.2.
Возможно подправили уже.