Пустая страница открывается по ссылке. Как хоть называется эта книга?

Да, действительно. Это тем более странно, что после заливки я проверил - файл был доступен.
Книга называется Linux Kernel Development Second Edition By Robert Lovе
Залил ее еще раз, на другой файлообменник - http://www.rapidshare.ru/148214

Хорошая книга, хорошо написана. Есть в продаже русский перевод - "Роберт Лав. Разработка ядра Linux. Второе издание"

ББК 32.973.26-018.2.75

Не со всеми утверждениями (или, точнее, акцентами) я согласен, как раз по поводу потоков.

Да, есть такая книга. Я себе прикупил. В принципе, читать можно. Есть, правда, проблемы перевода, но куда же без них.



С чем именно Вы не согласны?

у меня скачалось. Могу на ifolder залить
хттп://ifolder.ru/910949

Сообщение отредактировал Playnet - Jan 19 2007, 20:02

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



В этом clone и состоит беда Linux реализации.



Поменялось . Принципиально. Начиная с 2.6 модель потоков Linux стала гораздо ближе (в своём поведении, а не сколько в виде системных вызовов) к POSIX. А до этого был совершенно уродливый конгломерат, обязанный именно clone.

Посмотрите здесь:
http://www.books.ru/shop/books/357604
или хотя бы здесь:
http://qnxclub.net/files/articles/pthread/pthread.pdf


Ага, ща-а-а-з... а до Linux была, оказывается, голая пустыня ...
Потоки присутствуют во всех UNIX-like системах начиная с 80-Х ... ну, второй половины 80-х. И стандартизованы расширением POSIX1003.b.

Если программу предназначенную для работы на 1 cpu, программист пишет с использованием тредов, то ему еще долго шагать по пути к мастерству.




Уже много лет пользую потоки в linux, начиная с ядра 2.0, никаких бед что-то не замечено.

Имеется книженция "Unix. Взаимодействие процессов" Автор: Уильям Стивенс. Тамдовольно толково и про процессы и про потоки (правда немного теоретизировано). Куда слить?

http://nukeuploads.com/

Стоп-стоп.
Вы хотите сказать, что трэды это только для мультипроцессорных систем?

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

Книжку на днях постараюсь залить. Сообщу.



Спорное утверждение. Пока один поток ожидает завершение операции ввода-вывода, второй может использовать процессор. Конечно, потоки это лиш уровень абстракции, но организовать подобное БЕЗ потоков - еще тот гемор и, видимо, не всегда возможно. Общую производительность таким образом, конечно, не повысишь (процессор все-таки один), но так называемую "ощущаемую" - вполне.

Нет конечно Имелось ввиду приложение по теме, т.е. в uclinux, где SMP нет в природе а лишний гемор и потеря времени при написании тредовой app обеспечен. Работать такое приложение будет тоже медленнее - кроме тормозов при переключение контекста имеем дополнительные потери на счедулинг каждой треды и на организацию блокировок данных внтури одной и той же программы.
И последнее - неизвестно насколько эффективна реализована поддержка тредов в изначально ембеддерской однопроцессорной системе, где их активное использование, собственно, не предусмотрено. С нормальным linux'ом на обычном современном железе разница заметна только для маньяков скорости

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

Сообщение отредактировал InvisibleFed - Jan 21 2007, 11:39

Вы прокакое ядро говорите? Если про 2.6, то чуть раньше мы тут уже выяснили, что в нем треды реализуются через процессы с разделяемым адресным пространством (и другими данными). Т.е. являются объектами шедулинга и, соотвественно, объектами ядра.