Next Generation POSIX Threading project выпустил стабильный релиз за номером 2.0.0

binary-совместимость работает.
а вот если сделать файл s.c:
main(){}
и скомпилить его gcc s.c -lpthread, а потом загрузить ./a.out то выходит ошибка типа pth_init: <blahblah> can't чегототам shared/mapped memory. gdb говорит что был сигнал SIG33, и остоновилось все в libc. Вобщем гемор. Когда ngpd заменит LT тогда и буду юзать, а так - гемор.

p.s. kernel 2.4.19-pre10, glibc 2.2.5. все скомпилино саморучно.

Вот что я вычитал в mailing list'ах: "The binary RPMs supplied with this release are based on and built for use with a 2.4.19pre10 or better kernel that has the new "officially"
sanctioned support for NGPT. In addition it is necessary for you to apply
the new patch-futex-2.4.19 patch, included in this release. This patch is
based on new functionality already provided in the 2.5 kernel that will
eventually be backported to the 2.4 kernel and support. There is also a
patch, patch-kngpt-2.4.18, that is designed to be installed over a standard
2.4.18 kernel from kernel.org. NGPT takes advantage of the functionality
provided by these patches to efficiently handle mutexes, both shared and
non-shared. This patch is **ABSOLUTELY REQUIRED**. NGPT will not function
without it. The installation instructions have changed a bit as well since
1.2.2 and you should check the INSTALL file for the updated instructions."

Может быть в этом была проблема (еще не проверял). Не напоритесь.

Угу надо патчить ядро. 2.5 вроде как не надо там уже все есть.

Интересно, они стали вытесняющими или до сих пор корпоративная многопоточность?

2draky. там же ясно написано "It will add M:N threading capability and improve significantly on the POSIX compliance of pthreads on Linux". Если не понятно - объясняю. ngpt "гоняет" M юзеровских нитей на N ядреных. Считается, что это значительно эффективнее схемы M:M (см. книжульку UNIX Internals от Vahalia). Вытесняющая многопоточность может быть только между N ядерными тредами.

а как оно компарица с pvm?

> Вытесняющая многопоточность может быть только между N ядерными тредами.
И книжку правильную привёл, но ведь не читал же. Вытесняющая многопоточность может быть даже в pure user-land нитях. Вопрос, кстати, не праздный. Вытесняющую многопоточность между нитями, шарящими один и тот же rfork-еd процесс можно добиться двумя путями. Первое - используя non-blocking IO для дорогих read/write/etc syscalls, наплевав при этом на монополизацию процессорного времени одной нитью, находящейся в недорогом системном вызове (FreeBSD libc_r - именно этот путь -rfork).
Второй путь - это сделать _все_ системные вызовы асинхронными. FreeBSD KSE (коммит прошёл вчера) - это именно асинхронные системные вызовы плюс дополнительные трюки с upcalls в user-land scheduler.

Последний раз, когда я проглядывал исходники NGPT, я не нашёл в них ни того, ни другого. Просьба к тем, кто потратил на это больше времени, чем я, подтвердить или опровергнуть мои слова.

Не знаю как в этой версии но в планах проекта судя по ответам на этот же вопрос в их рассылке сделать вытесняемость.

> Второй путь - это сделать _все_ системные вызовы асинхронными.

ага и сделать ядро преемптив, что есть в QNX и нет в линухе, о чём я уже плакался на ЛОРе. В результате чего упадёт общая производительность, что критично для сервера, и за что я здесь получил по мозгам. Уж если делать, то через non-blocking IO. Кстати я уже спрашивал (самому смотреть лень) это сделано будет? кто-нибудь знает? А перекидывание тредов между user-space и kernel-space есть в планах?

>Последний раз, когда я проглядывал исходники NGPT, я не нашёл в них ни >того, ни другого. Просьба к тем, кто потратил на это больше времени, >чем я, подтвердить или опровергнуть мои слова.

ИМХО они вовсю юзают non-blocking IO. Более это делалось еще в pth которая предок NGPT

>И книжку правильную привёл, но ведь не читал же.

телепат что-ли?! покажи мне хотя бы одну реализацию scheduler activation (SGI не счет). а без чего-то наподобние SA нереально сделать userspace preemption. async I/O тут совсем не причем. оно всего лишь позволяет не блокироваться. умные, блин, все ...

> телепат что-ли?!
Да нет, бардак в некоей голове и невооружённым глазом видно.

Поехали разбираться:

> покажи мне хотя бы одну реализацию scheduler activation
Куски оригинальной публикации были реализованы ещё в Solaris 2.6, о чём было прописано в release notes.

> а без чего-то наподобние SA нереально сделать userspace preemption
А что есть userspace preemption в глазах благородного дона? В pure userland libc_r от FreeBSD нити диспатчатся по SIGPROF и никакого yield() не требуют. Никакого cooperative multitasking не наблюдаю.

> async I/O тут совсем не причем. оно всего лишь позволяет не
> блокироваться
И выполнять совершенно другую нить, пока орининальная ждёт окончания своего "синхронного" read? И переключиться на третью, если квант текущей уже истёк...

> МХО они вовсю юзают non-blocking IO. Более это делалось еще в pth
> которая предок NGPT
Пардон, слона я и не заметил. Действительно, они aliases определяют в pth_syscall.c.

>А что есть userspace preemption в глазах благородного дона? В >pure userland libc_r от FreeBSD нити диспатчатся по SIGPROF и >никакого yield() не требуют. Никакого cooperative multitasking >не наблюдаю.

_это_ нормально?! оно, конечечно, не cooperative. однако нах такая поделка не нужна. искали дешевое решение проблемы, а таперича scheduler вызываеца по сигналу. нет больше вопросов. тем более, что Господин очень желает видеть мою голову больной ...

> искали дешевое решение проблемы, а таперича scheduler вызываеца по
> сигналу.
А в кернеле по clock interrupt. SIGPROF посылается по выходу из кернел
режима в юзерланд, в подавляющем большинстве случаев как раз после
прерывания таймера. Вам есть дело до того, куда кернел возвращается,
раз уж прерывание всё равно произошло? Тогла Вы свои возражения по
существу изложите, без драматических сцен. Заодно представится
возможность предложить решение подешевле, блеснуть эрудицией, так
сказать.

> Господин очень желает видеть мою голову больной
Скорее свежей и отдохнувшей. Не берите близко к сердцу.

>> В pure userland libc_r от FreeBSD нити диспатчатся по SIGPROF

> _это_ нормально?!

уважаемые, если я хоть что-нибудь понимаю то:

единственная возможность квантовать время ЦПУ это запускать планировщик процессов по асинхронному событию связанному со временем. В случае ядра таким асинхронными событием является прерывание от таймера. В случае процесса (планировщик в user-space) асинхронными событиями в POSIXe являются только сигналы, занимать любой предопределённый из них это, как уже было сказано, поделка. Поэтому выхода два:

1. либо вводить новый сигнал, специально для user-space планировщика, что IMHO не трудно с точки зрения реализации, только придётся долго пинать людей занимающихся стандартизацией POSIXа, а дальше дело авторов библиотеки user-space тредов,

2. либо использовать kernel-space планировщик, что потребует его серьёзной переделки (он должен различать квантование времени процесное и тредовое), что уже потребует значительных усилий от кернел-хакеров и может быть не меньше от авторов библиотеки user-space тредов - зацепление между частями исполняемыми в kernel-space и user-space может быть не слабое (это уж как поделить обязанности), если например тред целиком заводится в user-space то переключать стеки должен kernel-space планировщик.

или я чего-то не понимаю?

я бы сказал, что система сигналов - это далеко не самый лучший механизм для этих целей. слишком overhead большой

> Занимать любой предопределённый из них это, как уже было сказано,
> поделка.
Не хуже и не лучше SIGUSR в Linux. Использовать setitimer по назначению - это вроде не крамола.

> я бы сказал, что система сигналов - это далеко не самый лучший
> механизм для этих целей. слишком overhead большой
Вот я и добиваюсь здесь сколько-нибудь содержательного ответа, что за оverhead за такой. Сигналы типа SIGPROF просто-напросто пользуюся context switch-ами от внешних событий, и всё, в чём они проявляются - это то, что процесс, прерванный прерыванием (таймера, к примеру), просто возвращается из kernel mode в user не в точку, где прерывание процесс настигло, а в обработчик сигнала. Где overhead?

> 1. либо вводить новый сигнал
На самом деле не проблема, просто пока никому не нужно оказалось.

> 2. либо использовать kernel-space планировщик
Сложно и неоптимально, см. SA paper.

3. Использовать гибрид, а.к.а. SA. Или async call gates by Terry Lambert :)

Народ, а прежде чем кидаться всякими умными терминами не слабо дать подборку ссылок или литературы? А то положим я знаю что такое scheduler activations, но вот call gates , KSE ...

PS На самом деле не вижу особого криминала в том чтобы заюзать сигнал, другой вопрос - для чего ? Для нотификации программы о том что kernel entity блокированы в ядре, это да... А вот для организации timeslicing ... ИМХО просто проще привязать нить к kernel entity если уж человеку нужен timeslicing... Все равно сам по себе timeslicing это уже большой overhead...

> Народ, а прежде чем кидаться всякими умными терминами не слабо дать
> подборку ссылок или литературы?
Можно здесь на ссылки посмотреть, к примеру:
http://people.freebsd.org/~julian/threads/

> call gates
Мистическая архитектура, много раз упоминаемая terry Lambert-ом, который до сего дня не сподобился привести её формальное описание. Похожа на KSE, судя по письмам, только контексты не привязаны в конкретным процессам, а создаются на лету только для syscalls, которые в них реально нуждаются.

> А вот для организации timeslicing ...
Опять двадцать пять! А как будет дешевле? Что-нибудь, кроме "нутром чую", есть в виде обоснования?

> ИМХО просто проще привязать нить к kernel entity если уж
Дорого. Не все твои нити будут находиться в kernel mode одновременно, но все будут ресурсы этого самого ядра потихоньку занимать. И куча других причин, с которыми ты должен быть знаком, коли читал SA paper.
Проще - да, согласен. Лучше ли - вопрос.

У меня при тестировании выдается сообщение

[root@workplace ngpt]# make test Open file: No such file or directory pth_init: opening/mapping shared memory failed.... Please send the following summary line together with details about the configuration (pth_acdef.h, pth_acmac.h, config.status, config.log) and build/test steps (output of 'make' and 'make test') to the author Bill Abt <babt@us.ibm.com> to help him in tracking down your platform problem.

NGPT: FAILED: i686-redhat-linux-gnu2.4glibc2.2 | sjlj/ssjlj/sas | down | 2.0.0

make: [test-std] Error 1 (ignored)

> 3. Использовать гибрид, а.к.а. SA. Или async call gates by Terry Lambert :)

попробую рассмотреть вышеописанные мной случаи и в особенности предложенный мне третий (с позиций не ядрёного девелопера, поскольку таковым не являюсь):

1. новый сигнал user-space планировщику:

(+) стандартный ядрёный сигнальный интерфейс,

(-) в ядре добавлен новый сигнал (что конечно просто в реализации), но из-за действий злоумышленника и/или по недосмотру сигнал до планировщика может не дойти,

(+) полная свобода в реализации user-space планировщика для авторов библиотеки тредов (в результате таких библиотек/планировщиков может быть сколько угодно),

(+) перфоманс ядра не падает,

(-) планировщик в user-space процесса, а посему не защищён по памяти от тредов;

2. kernel-space планировщик тредов:

(+) планирование тредов защищено по памяти от тредов,

(-) усложнение ядрёного планировщика (общий перфоманс _ядра_ падает),

(-) выдрать планирование тредов из ядра и заменить другим весьма проблематично,

3. гибрид:

напридумывать можно что угодно, проблема в том, что плохим разделением планирования тредов между kernel-space и user-space entry points можно превратить в entry holes ;-), ну не будем о грустном.

(-) передавать событие о решедулинге тредов из ядра в процесс можно только с помощью сигнала, значит новый сигнал (или некий колбек) вводить придётся всё равно (проблемы с ним смотри выше),

(-+) по крайней мере часть планировщика будет в ядре значит теряется гибкость в его реализации/смене, хотя и не так как для kernel-space планировщика тредов,

(+-) защита оного по памяти, но только его _ядрёной_ части,

(-+) перфоманс ядра падает хотя и не так как в случае полного kernel-space планировщика;

async call gates - это нечто вроде preemptive kernel? если так, то как я уже сказал выше (что мне ранее популярно объяснили), общий перфоманс системы падает, что для серверной ОС плохо. К тому же в есть известное изречение - "не множьте сущности без необходимости" ;-).

читать SA paper не удосужился.

> (-) планировщик в user-space процесса, а посему не защищён по памяти от тредов;
По памяти от тредов не защищены также всё данные процесса, все rw ммар регионы, етс. Злонамеренное повреждение любого из них для процесса может быть замечательно фатальным. Тебя это не беспокоит?

> (-) в ядре добавлен новый сигнал (что конечно просто в реализации),
> но из-за действий злоумышленника и/или по недосмотру сигнал до
> планировщика может не дойти,
Злоумышленник его съест? Если злоумышленник уже в твоём адресном пространстве, то не всё ли равно? А по недомотру можно и mutex не освободить... Cм. выше.

> аsync call gates - это нечто вроде preemptive kernel?
Это-то каким образом и из чего следует? Хоть ссылки-то искать пытался?

> читать SA paper не удосужился.
Зря.

> По памяти от тредов не защищены также всё данные процесса, все rw ммар регионы, етс. Злонамеренное повреждение любого из них для процесса может быть замечательно фатальным. Тебя это не беспокоит?

меня беспокоит что user-space планировщик даёт крекеру больше возможностей влиять на планирование тредов (если есть дырка в тредовом сервере), в случае kernel-space планировщика повлиять на планирование сложнее (покалечить его нельзя). Понятно что проблема в таком случае в дырке и исправлять надо её, но из-за user-space планировщика у крекера появляется дополнительная степень свободы. Ну не всегда же получение прав рута единственная и главная цель крекера?

также это будет беспокоить авторов библиотеки user-space тредов когда к ним будут приходить коры с комментариями "а не глючит ли у вас библиотечка?"

> > сигнал до планировщика может не дойти, > Злоумышленник его съест? Если злоумышленник уже в твоём адресном пространстве, то не всё ли равно? А по недомотру можно и mutex не освободить...

а от кривых рук страховаться не надо? их отрубание далеко не лучший способ.

> > аsync call gates - это нечто вроде preemptive kernel? > Это-то каким образом и из чего следует? Хоть ссылки-то искать пытался?

тут и искать нечего, гугл с первого раза выдал ссылку http://docs.freebsd.org/mail/archive/1999/freebsd-smp/19990704.freebsd-smp.html

и если не понятно из чего я сделал такой вывод привожу часть из http://docs.freebsd.org/cgi/getmsg.cgi?fetch=197471+0+archive/1999/freebsd-sm...

... Let's assume that all existing system calls which are of type "will always block" or of type "may or may not block" can now be executed asynchronously, and that this is not an attribute of a particular system call, but is an attribute of the call mechanism itself. We might also place in this category some of the "will never block" calls, if they take "a long time" to complete.

This, in a nutshell, is the "async call gate". ...

а если вспомнить что такое преемптив кернел - кернел который позволяет сделать "преемпт" процесса в произвольный момент даже в kernel-space - то не пахнет ли тут asynchronous system calls? Я не ставлю между ними знак равенства, но IMHO преемптив кернел без asynchronous system calls невозможно.

> > читать SA paper не удосужился. > Зря.

давай ты не будешь говорить что мне делать, а я не скажу куда тебе идти?

с уважением, anonymous.

> а от кривых рук страховаться не надо? их отрубание далеко не лучший
> способ.
Почему именно от этих кривых ручек страховаться страсть как надо, а от другого совершенно эквивалентного класса проблем не надо? О какой дополнительной свободе для кракера приходится говорить, если он уже исполняет свой код внутри вашего процесса?

> то не пахнет ли тут asynchronous system calls?
Не пахнет совершенно. Syscall может быть прерван в любое время и неограниченное количество раз, с точки зрения процесса же он как был, так и остался cинхронным.

> IMHO преемптив кернел без asynchronous system calls невозможно.
Страное у тебя ИМХО. Ещё как возможно. Тебе пожалуй стоит пояснить общественности, что есть asynchronous syscalls в твоём понимании, и почему ты с достойным лучшего применения упорством стараешься свалить в кучу ортогональные сущности.

Предлагать прочитать SA paper _теперь_ уже не буду. Приведённые тобой выше цитаты и выводы, тобой из них сделанные, разуверили в полезности данного мероприятия.

> О какой дополнительной свободе для кракера приходится говорить, если он уже исполняет свой код внутри вашего процесса?

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

> Тебе пожалуй стоит пояснить общественности, что есть asynchronous syscalls в твоём понимании,

перевожу дословно: a(не)-syn(связь)-chronous(временой) sys(системный)-calls(вызовы) - системные вызовы которые могут быть запущены во времени (реальном!) не зависимо друг от друга. Привожу ещё раз определение преемтив кернел: кернел который позволяет прервать процесс даже в сисколе, чтобы выполнить какую-то работу, например, обработать прерывание и, возможно, запустить какой-то _асинхронный_(иначе лок!) прерванному сискол. Теперь я попрошу в лице общественности - вас (мы уже вроде на вы перешли?), дать мне определение асинхронного сискола отличное от моего.

> Предлагать прочитать SA paper _теперь_ уже не буду

ну почему же, ссылочку можно оставить? плиз, ;-)

с уважением, anonymous.