LINUX.ORG.RU

The Next Generation POSIX Threading Project


0

0

IMHO интересная новость, хорошего проекта:

12 March 2002: Linux Kernel 2.4.19pre3 now has the NGPT support built in. Using this kernel and higher, you will no longer need to patch the Linux kernel for NGPT support.

9 March 2002: Release 1.2.0 was posted to the site. NGPT Release 1.2.0 is a stable release of the NGPT 2.0

>>> Подробности



Проверено:

А кто рубит в этом NGPT? Со стороны програмера это будут теже posix threads но реализация будет типо лучше? А что щас все так запущено в линухе?
Вот мне в проге на c++ нужно будет что-нибудь переделать чтобы с обычных linusthreads перейти на NGPT или нет?
На сайте man IS COMING SOON (tm).

anonymous
()

Понадобится только перекомпилировать твою прогу. А текущее положение с потоками в линуксе очень плохое.

Ogr
()

Одно радует, с ограми в линуксе еще хуже...

anonymous
()
Ответ на: комментарий от Ogr

Сдается мне, что не только в Линуксе с потоками все плохо, но и вообще в UNIX. И будет там все плохо с потоками до тех пор, пока ввод-вывод там будет синхронный и сигналы с негарантированной доставкой.

Поясню мысль. read/write, как известно, блокирует весь процесс, что лишает смысла читать что-то одним потоком, а писать другим.

Если сейчас в линухе потоки реализованы с переключением в user-space, а будет реализован механизм ala Solaris/(не уверен)Windows/OpenVMS7.xx c lwp/kernel scheduling, то это даст, конечно, некоторый выйгрыш по производительности и некий профит при использовании нескольких процессоров. Но не решит главной проблемы.

Конечно, мне могут возразить. Вот есть aio и все такое... Но, aio--сугубо непероносимо и реализовано не везде и по-разному. Где-то можно читать только из файлов, где-то и из сокетов тоже.

Да и сигналы в UNIX __очень_дороги__. Насколько я помню, уведомление о завершении операции при использовании aio выполняется сигналами.

Поэтому, потоки можно использовать только для какого-то рендеринга, отрисовки в памяти, параллельной математики. Но таких задач мало. Интересен ввод-вывод.

В общем, при использовании потоков, процедур завершения. заповнеданных нам DECом сильно не хватает.

Поэтому, видимо, технология select/accept/fork останется с нами еще долго.

gns ★★★★★
()

Зато fork в Linux _очень_дешев_.

anonymous
()
Ответ на: комментарий от gns

gns wrote:

> Поясню мысль. read/write, как известно, блокирует весь процесс,
> что лишает смысла читать что-то одним потоком, а писать другим.

ты серьезно? а попробовать религия не велит?

anonymous
()

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

chuchelo
()

Ngpt уже сейчас божно ставить и пробовать вместо linuxthreads.
По теории проги должны стать быстрее и легче. Но там есть одна проблема.
Преимущества нитей ngpt на SMP не будет.

anonymous
()

Складывается впечатление, что люди здесь высказывают свое мнение о потоках в линуксе, начитавшись желтой прессы 3-х летней давности.

surfer
()

Цитаты из классиков:

from Larry McVoy's home page:
//-------
"A computer is a state machine. Threads are for people who can't program state machines."
//-------

Alan Cox (http://marc.theaimsgroup.com/?l=linux-kernel&m=99254377501835&w=2)
//--------
There are really only two reasons for threaded programming.

- Poor programmer skills/language expression of event handling

- OS implementation flaws (and yes the posix/sus unix api has some of these)

Co-routines or better language choices are much more efficient ways to express
the event handling problem.

fork() is often a better approach than pthreads at least for the design of an
SMP threaded application because unless you explicitly think about what you
share you will never get the cache affinity you need for good performance.

And if you don't care about cache affinity then you shouldnt care about
pthread_create overhead because quite frankly pthread_create overhead is easily
mitigated (thread cache) and in most real world applications considerably less
of an performance hit

Alan
//-------

anonymous
()

2gns: по всей видимости вы просто не знаете как реализован нынешний
LinuxThread. Тем более далать таких безответственных заявлений
за "вообще UNIX" не стоит, просто вы товарищ глупо выступили.
Нинешние потоки в Linux реализованы one to one. Т.е. один
kernel pcb отражается на один thread user space задачи.
цель же ngpt сделать модель one to many. Что будет несколько дешевле
с точки зрения ядра. Теперь за "вообще UNIX" - поддержка threads
в Solaris просто выше всяких похвал. Там есть несколько типов
sheduler для threads. В IRIX победнее но тоже не плохо.
Теперь насчет "сигналов с не гарантарованной доставкой" - советую
выучить мат часть, а только потом выступать с громкими заявлениями.
Сигналы с гарантированной доставкой есть и вопрос только в том каким типов сигналов вы пользуетесь.
Насчет блокируемого io вы облажались. Другие threads в процессе не
блокируются если в каком либо thread обьявлен io по той простой
причине что sheduler рассматривает thread как отдельный процесс.
Вопрос только в возможности самой VM прервать system call и передать
управление другому syscall. Так что вы спутали. На последок,
здесь встречаются юнные программеры которых ваши безграмотные заявления могут испортить и они впрям начнут думать
что лучше Windows threads ничего нет.
Да кстати что бы лучше спалось почитайте на ночь исходники LinuxThreads может проясниться такой простой факт что и fork и pthread_create реализованы через clone. А вообще мне даже нравится
как полубезграмотный в программировании народ лезет обсуждать вещи
в которых вообще ничерта не понимает. Смешно да и только ... :)

anonymous
()
Ответ на: комментарий от anonymous


> Цитаты из классиков:
> "A computer is a state machine. Threads are for
> people who can't program state machines."

Да-да-да. А машины для тех, кто не умеет ездить на
велосипеде.

P.S. Надо же, "классики"... Своей головой-то подумать сил,
что ли, нет?

anonymous
()

Действительно.
Классики в молодости заучили некоторые догмы, вот потом и рассказывают, что они знают единственный правильный путь и что раньше трава была зеленее.

>На последок,
>здесь встречаются юнные программеры которых ваши безграмотные
>заявления могут испортить и они впрям начнут думать
>что лучше Windows threads ничего нет.

Виндовые нитки не самые лучшие, но тем не менее, их реализация весьма достойна, в отличии от.

Havoc ★★★★
()
Ответ на: комментарий от anonymous

> Да-да-да. А машины для тех, кто не умеет ездить на

Нет!!! Машины для тех, кому в падлу ездить на общественом транспорте.

> Надо же, "классики"... Своей головой-то

Еп-те... Ты сначала опровергни эти классиков... желательно на деле.

anonymous
()

хехе, просотй пример, создание трида и тутже выход из него. Сравните разные версии линуха за сколько секунд 100000 таких операций в одной программе можно сделать :-))) у меня получалось что 2.2 гораздо быстрее 2.4 :-)

chuchelo
()
Ответ на: комментарий от anonymous

>А вообще мне даже нравится >как полубезграмотный в программировании народ лезет обсуждать вещи >в которых вообще ничерта не понимает. Смешно да и только ... :)

А меня это просто бесит!

>Преимущества нитей ngpt на SMP не будет.

Дружище! Иди милый и почитай хотя бы описание этой штуки, если западло залезать в исходники !

>цель же ngpt сделать модель one to many ~~~~~~~~~~~ Вот ключевые слова. Обрати внимание. Вообще говоря с ngpt можно получить и one-to-one. Насколько я помню там можно указать максимальное к-во потоков для одного LWP. ( при превышении стартует следующий LWP )

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

С наилучшими пожеланиями, Сергей.

anonymous
()
Ответ на: комментарий от chuchelo

Цифры свои приведи и образец проги заодно. Но сразу говорю - пример жутко
синтетический и не real life.

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

Здравствуйте, Господа хорошие!
Вот почитал я что тут написано и мне плохо стало...
По поводу Linux-thread:
Для его создания необходимо:
1. Саллоцировать страничку
2. Выделить новый пид
3. Копировать старый task_struct в новый
4. Сделать atomic_inc(mm->count), atomic_int(fs->count), и добавить процесс (извините нитку) в очередь... Всё! А что тут долгово? Страничку перекопировать? по моему нет...(для более любознательных linux/kernel/fork.c ф-я do_fork)
По поводу реад/врайт: дак конечно, перед тем как делать врайт делается __grab_page_cache которое полочит страничку и пока врайт для это странички не пройдёт реад тоже делаться не будет...Но любой другой пожалуйста(смотри linux/mm/filemap.c ф-я generic_file_write ) И только идиот(простите...) будет организовывать IPC через реад-врайт... Я бы это сделал через mmap+какой-нить семафор на крит область где я меняю какие данные валидны... И никакой блокировки нету... Вообще. Пиши читай, делай всё что твоей душе угодно...
И ещё чем сигнала на линуксе дороги и что значит "негарантированная доставка сигнала"... Если ты кому-то послал сигнал (через sys_kill) то это сигнал до него дойдёт, если он не его не заблокировал... Конечно если ты пошлёш сто сигналов то sig_handler вызовется один раз - это и не удивительно - так в POSIX сказано...
И ещё - если машина не СМП то как только ты послал сигнал тебя прервут и передадут упроавление тому, кому этот сигнал был послан....
Malfet

anonymous
()

2 anonymous (*) (2002-03-22 12:14:26.0) Сам-то понял что сказал?

PitStop
()

Дабы не плодить здесь флейм я признаю себя неправым ибо документ, описывающий оригинальные GNUth и LinuxThreads, который лежит на страниче проекта NGPT устарел. Как только я выясню проблему, я выскажу свои комментарии. Свое замечание я основывал на небольшом опыте программирования с использованием threads для linux/solaris и значительном(многолентнем) опыте программироввания многопоточных приложений для OpenVMS.

Если был неправ - извинеите.

gns ★★★★★
()

Thread - весьма удобная штука.
Поначалу не мог понять где их лучше использовать.
Теперь вот не могу понять как раньше без них обходился.
Хотя можно, конечно, переделать программу c нитями на селекты.
Но уверяю вас, она от этого лучше не станет.

К слову, сегодня только доделал один embedded проект на rabbit 
процессоре, так там 6 нитей. И код получился весьма и весьма красив.
То же самое без нитей если и возможно сделать, то это будет просто 
нечитаемо. Надеюсь что никто не поспорит что красивый код работает 
лучше некрасивого? :-)

alman ★★★
()
Ответ на: комментарий от chuchelo

>хехе, просотй пример, создание трида и тутже выход из него. Сравните >разные версии линуха за сколько секунд 100000 таких операций в одной >программе можно сделать :-))) у меня получалось что 2.2 гораздо быстрее >2.4 :-)
>chuchelo (*) (2002-03-22 11:52:41.0)

Kernel-space нитки появились только в 2.4, а в 2.2 были user-space.
Так что не удивительно.

anonymous
()

Молодец gns ! Не многие способны тут признать своб ошибку, чашще просто исчезают "по английски".

anonymous
()

Нда. Что за чушь про нити в 2.2 ? Они там были такие же kernel level как и в 2.4. Далее касаемо скорости - создается / выходится поток то быстренько 20K в секуну pthread_create()/pthread_join() на PIII 500 это достаточно для большинства задач. Тем более что на мой взгляд хорошим тоном является использование пула потоков а не создание их на каждый чих. Другая проблема более фиговая для потоков в linux это то что по умолчанию со стеком в 2M их не создашь более 1024 а чтобы его поменять надо GLIBC патчить. Еще одна прелесть - это скорость переключения контекстов которая падает очень сильно с числом потоком. Так при паре потоков делающих shed_yeld() получаем около 200K а в случае 1000 уже всего около 2K к счастью эту проблему частично лечит Ingoвский шедулер

anonymous
()

Очень здорово, что человек признал, что был неправ.

Это значит - хороший человек. Грамотный и порядочный.

Однако, хорошие люди есть. Это радует.

:)

and3008

anonymous
()

Народ, что так грустно обсуждаем ? Почему не видно бурной радости ? :-) Этот же проект призван закрыть любимую тему наездов на линух - "хреновые" треды. Так как когда он завершится нитки у нас будут как в Солярке, особенно в текущей нише ( 4-8 процессоров) Так что ура и еще раз ура ! Я про этот проект слышал, но не думал что уже есть рабочие версии. Кто-нибудь с хорошим опытом в ниточном программировании - протестируйте , а ? Типа на задаче с кучей ниток ?

kernel ★★☆
()
Ответ на: комментарий от kernel


2kernel (*) (2002-03-22 19:15:34.0):
> нитки у нас будут как в Солярке,
НЕТ!
Если нитки будут "как в солярке", то на i86 оно работать не будет.

Die-Hard ★★★★★
()

2 Die-Hard (*) (2002-03-22 22:37:32.0)
Нельзя ли пояснить, почему? LWN < N threads помоему не плохо, хотя бы
по количеству переключений контекста..

Toster
()

Вот вам предварительные тесты для mysql. Сравнивался бинарный i686 дистрибутив 3.23.40
c сайта mysql и собранный собственноручно с поддержкой NGPT. Ядро 2.4.19-pre3.
Гонялся fork_big.pl из каталога /test в дистрибутиве mysql. Он создает заданное кол-во процессов.
Опции: --loop-count=5000 --threads= {1,5,10,20,50,100}. Замерялось время исполнения.

mysql-linuxthreads:
1 - 0m9.8s
10 - 1m24s
20 - 4m21s
50 -14m47s
100 - не испытывалось (жаль терять время)

mysql-ngpt
1 - 0m9.5s
10 - 0m51s
20 - 1m44s
50 - 4m29s
100- 9m50s

Линейная скалябельность. Фантастика. Солярис отдыхает?
Кому еще нравятся linuxthreads? Кстати, заметьте, статичный бинарник
оригинального mysql собирался с патчееными (улучшенными) linuxthreads...



anonymous
()

2anonymous (*) (2002-03-23 01:32:55.0): "Линейная скалябельность"
Ну линейной зависимостью там и не пахнет, а вот результаты по сравнению со стандартными потоками действительно хорошо смотрятся. Замерить бы это не в попугаях, а в чем-нибудь одинаковом...

Ogr
()

Если нитки будут "как в солярке", то на i86 оно работать не будет.

?. Ты хочешь сказать что в Solarix/X86 нитки не работают ?
Или они там так подзаложились на свою архитектуру что
на X86 все скалится хуже чем linuxthreads ?

kernel ★★☆
()

To: anonymous (*) (2002-03-23 01:32:55.0)

Как ставил ngpt и как компилировал mysql?
Меня mysql послал со словами: "это линукс, а linuxtreads нет, ..."

Settler
() автор топика
Ответ на: комментарий от Settler

> Как ставил ngpt и как компилировал mysql?

Обязательное требование - ядро >= 2.4.19-pre3, либо придется патчить.
Ставится легко. NGPT замещает собой linuxthreads полностью. В Makefile'e
есть таргет "uninstall", который возвращает linuxthreads на прежнее место.
Поэтому опыт безболезненный.

> Меня mysql послал со словами: "это линукс, а linuxtreads нет

А знаешь, как mysql проверяет наличие linuxtreads? `grep Linuxtreads /usr/include/pthread.h`.
Так пропиши строчку /* Linuxtreads */ в самом начале этого файла...
Еще одна тонкость - не пытайся собрать статический mysqld. Команда NGPT
переопредилила sigprocmask, и возникают конфликт с libc.a.

anonymous
()

Опечатка:
s/Linuxtreads/Linuxthreads/

anonymous
()
Ответ на: комментарий от Ogr

> Ну линейной зависимостью там и не пахнет

Что, за живое задело ;)) Бывает... Тебе домашнее задание - график нарисуй.

> Замерить бы это не в попугаях, а в чем-нибудь одинаковом...

Ослеп что ли от злости к линуксу? Не заметил, что тестировался реальный db-сервер?

anonymous
()

2anonymous (*) (2002-03-23 18:15:41.0): "Что, за живое задело ;)) Бывает... Тебе домашнее задание - график нарисуй"
Ты карандаш в руках деражть умеешь? Вот и нарисуй, только не забудь минуты в секунды перевести, художник блин.
"Не заметил, что тестировался реальный db-сервер?"
Я конечно понимаю, что с образованием сейчас очень туго и уже не вскому объясняют, что при тестировании нужно точно указывать на чем тестировали, хотя я подозреваю, что анонимусов выпускают из первого класса, только только чтоб читать и писать по слогам умели, а думать это уже лишнее.

Ogr
()
Ответ на: комментарий от Ogr

> нужно точно указывать на чем тестировали

Очнись, товарисч. Тестировалось на одной и той же машине. То есть этот показатель - константа.
Параметры софтин указаны точно. Тест проводился на athlon-1400/1G/IDE.
Не знаешь за что зацепиться?

anonymous
()
Ответ на: комментарий от Ogr

> Ты карандаш в руках деражть умеешь?
Ogr, вообще-то для таких дел компутер и предназначен...
А для тебя рекомендуемая литература: Алгебра, 7-й класс, тема "Линейная функция"
Не стесняйся ;)

anonymous
()

2anonymous (*) (2002-03-23 21:16:42.0): "Тестировалось на одной и той же машине"
Блин, еще раз, мне интересно как это выглядит по отношению к другим ОС.
2anonymous (*) (2002-03-23 21:55:10.0): "А для тебя рекомендуемая литература: Алгебра, 7-й класс, тема "Линейная функция""
Марш, в школу в 4 класс изучать дроби, если уж рисовать не умеешь. Я уж не говорю о том, что если бы там была линейность, то это был бы всего лишь показатель отстойности реализации.

Ogr
()

народ, кто-нибудь в сырцы лазал? нити в одном user-space блокируются при I/O? (I/O non-blocking или нет? если нет, то об этом помнить придётся, а если да, то мои поздравления авторам NGPT, автор Linux PThreads писал что это та ещё задачка) Знакомый давно рассказывал о реализации тредов в DIGITAL UNIX, что есть возможность перекидывать тред из user-space в kernel-space и обратно, тут что-нибудь подобное есть?

anonymous
()

Какие "другие ОС" тебя интересуют? Солярис?

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

2Settler: "Какие "другие ОС" тебя интересуют?"
FreeBSD5.0-Current
"Солярис?"
На х86? Спасибо не надо.

Ogr
()

>>"Спасибо не надо". Ну так и проверь на FreeBSD, какие проблемы? :-)

Settler
() автор топика
Ответ на: комментарий от Ogr

> Блин, еще раз, мне интересно как это выглядит по отношению к другим ОС.
1) Другие ОС обсуждаются на соответсвующих сайтах, где собираются знатоки этих ОС.
2) В нужной тебе ОС в ядре еще не реализованы необходимые для ngpt сисколы.
3) С какой радости кто-то должен делать тесты для "твоей ОС"?
И вообще пошел нафиг отсюда, проституоид.

anonymous
()
Ответ на: комментарий от Ogr

Да ты рехнулся малый. Дроби зачем-то приплел.

> если бы там была линейность, то это был бы всего лишь показатель
> отстойности реализации

Лучше заткнись, тупость твоя воистину безгранична. Тебя даже не интересно
опускать уже. Все равно что убогого калеку обижать.

anonymous
()

2anonymous (*) (2002-03-24 02:40:17.0): "2) В нужной тебе ОС в ядре еще не реализованы необходимые для ngpt сисколы"
Глупенкий ты. Реализация на FreeBSD5.0 изначально сделанна с головой, а ни как в линуксе.
"3) С какой радости кто-то должен делать тесты для "твоей ОС"?"
Что бы понять как результаты выглядят при сравнении разных ОС.
"И вообще пошел нафиг отсюда, проституоид"
Шо, ты такой сегодня. Тебя что в очередной раз опустили?
2anonymous (*) (2002-03-24 02:45:58.0): "Да ты рехнулся малый. Дроби зачем-то приплел"
И этот, мудак, еще вспоминал про линейные функции (намек - чем является коэф. в линейной функции). В общем я так понял ты до 4 класса еще не дорос.

Ogr
()

2OGR
завиимость некая парабола, но очень пологая, т.е. при некой апроксимации похожа на линейную.

anonymous
()

Забавно. Пердунишке ОГРу показали реальный результат развития линукса, новая софтинка оказалась намного быстрее старой. Правда мальца это так смутило, что он ни нашел ничего другого как придраться к слову "линейная". Если уж собрались тупить, то экстраполяция вобще не имеет смысла пока не указана погрешность измерения. Тоже мне нашлись экспереминтаторы хреновы.

Кстати, я понял в чем состоит польза всяких Огров для развития Linux. Эти черви выискивают слабое место Линукса по сравнию с закрытыми продуктами и начинают поднимать злорадный шум по этому вопросу. В результате, к этому слабому месту привлекается повышенное внимание и какой нибудь толковый паренек загорается идеей внести усовершенствование.

Сколько тут на LoR перемыли костей и VM и treads и вопросам RealTime и что мы видим? Развиваются все обсуждаемые компоненты, равзиваются семимильными шагами!

Огромное спасибо ОГРам, IRsям во всем мире за ваше ковыряние в поисках дерьма. Находите больше дерьма, мы, линуксоиды, его будем преврщать в конфетку!

P.S. Вот толко не надо цепляться к линейным функциям, не вашего уровня это полет! Углубляйтесь в самую сущность, мы ждем вашей помощи! :)

anonymous
()

Забавно. Пердунишке ОГРу показали реальный результат развития линукса, новая софтинка оказалась намного быстрее старой. Правда мальца это так смутило, что он ни нашел ничего другого как придраться к слову "линейная". Если уж собрались тупить, то экстраполяция вобще не имеет смысла пока не указана погрешность измерения. Тоже мне нашлись экспереминтаторы хреновы.

Кстати, я понял в чем состоит польза всяких Огров для развития Linux. Эти черви выискивают слабое место Линукса по сравнию с закрытыми продуктами и начинают поднимать злорадный шум по этому вопросу. В результате, к этому слабому месту привлекается повышенное внимание и какой нибудь толковый паренек загорается идеей внести усовершенствование.

Сколько тут на LoR перемыли костей и VM и treads и вопросам RealTime и что мы видим? Развиваются все обсуждаемые компоненты, равзиваются семимильными шагами!

Огромное спасибо ОГРам, IRsям во всем мире за ваше ковыряние в поисках дерьма. Находите больше дерьма, мы, линуксоиды, его будем преврщать в конфетку!

P.S. Вот толко не надо цепляться к линейным функциям, не вашего уровня это полет! Углубляйтесь в самую сущность, мы ждем вашей помощи! :)

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