про потоки в линуксе

[nadge]

Собственно, как они реализованы (fork, общее адресное пр-во и т.п.) я примерно представляю. Интересует, насколько это эффективно (в плане производительности, расходования памяти и т.п.) в сравнении хотя бы с той же виндой.

З.Ы. Просто внешне выглядит как костыль.

[drBatty]

З.Ы. Просто внешне выглядит как костыль.

А это и есть костыль(сейчас будут бить) - судите сами: один процессор заставляют делать две задачи сразу. В winNT реализовано примерно так-же эффектно как в Linux(сейчас вообще убьют). В DOS(win9x/Me) вообще отсутствует.

[nesk]

Собственно, как они реализованы (fork, общее адресное пр-во и т.п.) я примерно представляю. Интересует, насколько это эффективно (в плане производительности, расходования памяти и т.п.) в сравнении хотя бы с той же виндой.

З.Ы. Просто внешне выглядит как костыль.

это вы на них не правильно смотрите. совсем это не костыль.
Даже не представляю с какой стороны это выглядит как костыль. Костыль к чему?

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

По поводу термина "поток": в unix системах есть такая вещь как stream, и это слово никак кроме как "поток" не переведёшь. Поэтому thread на русском надо бы называть или "нить" или длинно "поток команд"

Может корректней было бы сравнивать многонитивые программы с "многопроцесснами" программами (программами, которые для выполнение параллельных действий создают отдельный процессы )

Так вот нити процесса имеют общее виртуальное адресное пространство. Что из этого следует?
1) несколько независимых потоков команд которые имею общую память без посредничества ОС, не надо использовать IPC
2) Даже если процессор один, когда происходит переключение процессов на процессоре (CPU) (переключение контекста) Все кеши процессора помечаются как испорченные (грязные), тоже самое происходит и с TLB процессора (Потому что новый процесс работает в другом виртуальном адресном пространстве, то есть его виртуальные адреса должны транслироваться совсем в другое адреса страниц физической памяти).
А если на CPU происходит переключение между нитями одного процесса, то мы остаёмся в том же виртуальном адресном пространстве и кеш и TLB процессора не портятся.

Мда.. не очень понятно объяснил

.
И еще !!
Нити (потоки команд) создаются не при помощи fork, а при помощи clone.
С помощью fork как раз таки создаются новые процессы.(Правда процесс в современном представлении - это просто контейнер для нитей и после fork будет создан новый процесс, в котором конечно будет одна нить.)

Короче, Вам бы надо какую-нить книжку почитать.
Но вот на ум ничего не приходит.
Может стоит начать с Робачевского "Операционная система Unix"

[BlackStar]

Нити (потоки команд) создаются не при помощи fork, а при помощи clone.

В любом случае вызвается do_fork, естественно с разными аргументами.

ЗЫ. Кстати мне тоже не понятно почему это потоки(нити) в Linux это костыль?

[drBatty]

ЗЫ. Кстати мне тоже не понятно почему это потоки(нити) в Linux это костыль?

Потому, что для того что бы ходить необходимы две ноги. Если у вас(не дай Бог) одна - вам понадобится костыль. Для решения двух задач одновременно надо 2 компьютера. На одном тоже можно, но не так эффективно как на двух. И ещё дополнительные подпорки нужны ввиде особого процессора, и особой ОС.

про эффективность в сравнение с виндой.. (пытаюсь подобрать слова) мне кажется - это глупый вопрос.

Интерестно, а в чем хуже?

[BlackStar]

Потому, что для того что бы ходить необходимы две ноги. Если у вас(не дай Бог) одна - вам понадобится костыль. Для решения двух задач одновременно надо 2 компьютера. На одном тоже можно, но не так эффективно как на двух. И ещё дополнительные подпорки нужны ввиде особого процессора, и особой ОС.

Причем здесь Linux?

[drBatty]

Причем здесь Linux?

не причём. В winAPI вообще какие-то дикие нити/процессы, я так и не понял, как ими пользоваться

[nesk]

Интерестно, а в чем хуже?

Я не говорил про хуже или лучше!


ЗЫ Сейчас меня осенило! Все прояснилось. Мне кажется, просто nadge думает, что в unix есть только процессы, а в windows только нити.

рекомендуется к прочтению man pthreads

[Portnov]

А очень известная книжка. Э.Реймонд, "Искусство программирования для UNIX".
Суть в следующем. Программы с многими нитями - это в принципе костыль (да, иногда без него никак не обойтись), т.к. нити - это сложный в реализации, часто небезопасный и ненадежный (в плане защиты от дурака на месте программиста) механизм взаимодействия между процессами (IPC). В системах, где другие методы IPC развиты слабо и сложны в использовании (примеры: win32, vms), нити становятся одним из главных механизмов IPC. В unix традиционно хорошо развиты простые и эффективные методы IPC (сигналы, пайпы, сокеты, shared memory, в конце концов sysV message queues и STREAM), и нити обычно вообще не нужны. Хотя да, вполне можно напридумывать примеров задач, в которых самым эффективным решением будет иметь несколько процессов в одном адресном пространстве (т.е. нитей). Именно поэтому в современные unix-системы всё-таки добавили возможность создания нитей.

[nesk]

Для решения двух задач одновременно надо 2 компьютера.

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

Так вот, многозадачность на одном процессоре называется модным сейчас словом - виртуализация. Каждой задаче кажеться что она одна монопольно использует все время CPU и все адресное пространства памяти.
А основное приемущество виртуализации - это повышения процента утилизации.
Тоесть многозадачность дает возможность более эффективно использовать возможность моей вычислительной системы.

[AWSVladimir]

Тоесть многозадачность дает возможность более эффективно использовать возможность моей вычислительной системы.

А можно мне?

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

PS:
За все время работы (15 лет) программером, делал нити, только ради теста/изучения.
Ну вроде 1 или 2 раза были в проекте, когда данные выводятся на экран (быстро), а потом в фоне обрабатываются и по запросу подставлялись обработанные. Но эт было еще на вин98.

Теперь вся работа только по запросу (порционно).
Программа выполняется со скоростью просто фантастичекой и неукладыв-ся в головы 95-2000 годов.
Поэтому давно уже отказались от нитей.
Если что то нужно запустить параллельно, то заускаем отдельным процессом и позволяем самой операц. системе управлять такими "нитями" .

PS: Напишите, для чего хотите применить нити/потоки.
Просто интересно.

[nesk]

Тоесть многозадачность дает возможность более у.
Нити жрут процессор, но по остаточному принципу. В винде приоритет равен или ниже приоритета головной программе (в лине тоже).

Насколько я понимаю, в современных ОС единицей планирования является нить, а не процесс.
Как я писал выше, нити позволяют уменьшить количество накладных расходов при переключении контекста на CPU.
Нити почти всегда применяются, когда создаётся сервер для сетевого приложения. Тут для обработки каждого запроса, стартует своя нить.
Можно в качестве примера рассмотреть реализацию NFS сервера (в HP-UX).
При работе NFS по UDP протоколу, для обработки запросов клиентов стартуют отдельные процессы. Что интересно процессы стартуют сразу при старте сервера и их количество тоже определено заранее (обычно 16 штук). А дальше процессы весят в памяти и либо ничего не дают, либо максимально в один момент времени могут обрабатывать лишь 16 запросов (остальные запросы будут накапливаться в буфере udp сокета, а он может переполниться).
А для работы NFS по верх TCP, запускается один многонитевой процесс, и для обработки каждого запроса стартует новая нить.
все современные веб сервера - многонитевый.

[Debris]

nesk, хм, у меня сейчас есть предмет в универе Real Time Operation System, насколько я понял основой планирования ос все таки являются управление процессами и их потоками. Кстати чем отличается нить от потока кто нибудь может обьяснить?

[nesk]

Кстати чем отличается нить от потока кто нибудь может обьяснить?

в данном контексте ничем, по английски это thread

[BlackStar]

все современные веб сервера - многонитевый.

Если мне не изменяет память, самый что ни на есть современный веб сервер - Apache - использует потоки, а не нити.

[nesk]

все современные веб сервера - многонитевый.

Если мне не изменяет память, самый что ни на есть современный веб сервер - Apache - использует потоки, а не нити.

В данном контексте потоки и нити это одно и тоже!
Я же писал выше, что по английски это будет thread. Я так же написал причину того, что я использую термин "нить", а не "поток"
А вопрос был в противопоставлении многопоточных (или многонитевых (как синоним)) приложений и приложений, которые используют для организации параллельных действий несколько независимых процессов плюс средства IPС для обмена данными.

[Debris]

nesk, так тогда и писал бы thread или поток, ведь есть же еще и fibers (волокна), собственно про них я и подумал.

[BlackStar]

Если мне не изменяет память, самый что ни на есть современный веб сервер - Apache - использует потоки, а не нити.

Блин, процессы конечно же.

[drBatty]

Блин, процессы конечно же.

Господа, определимся с терминологией?

[xorader]

2Nesk: респект за обьяснения (я бы уже давно плюнул).

В апаче используется и то и то (в зависимости от настроек и сборки). Смотрите в сторону: mpm-worker и тд...

В ядре 2.4 нити действительно реализованы были не очень хорошо (практически только на уровне библиотек). Начиная с 2.6 - на уровне ядра (шедулер ядра) - т.е. стало сравнимо с Free(*)BSD системами.

> Программы с многими нитями - это в принципе костыль....

Смотря для каких задач. Nesk очень грамотно описал примеры.

[drBatty]

Неправда
вот я сейчас сижу в интернете, слушаю музыку,пишу отчет в ворде, общаюсь в аське. И все это на одном процессоре, при этом утилизация процессора не более 15%.

Ну и что, если за год надо дойти до туалета, можно и с костылём

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

[pryga]

В системах, где другие методы IPC развиты слабо и сложны в использовании (примеры: win32, vms), нити становятся одним из главных механизмов IPC.

Почему в винде методы IPC слабы и сложны? Каналы, проецируемые в память файлы и тп и тд там вполне нормально работают.
Нити не могут быть механизмом IPC, так как по определению - IPC == interprocess communication, то есть взаимодействие между процессами, а это разные вещи.
К слову, переключение между нитями осуществляется быстрее, нежели между процессами, так как нити находятся в виртуальном адресном пространстве одного процесса.

PS: Напишите, для чего хотите применить нити/потоки.
Просто интересно.

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

[drBatty]

Ну например. Нужно найти слово. Пусть ищем в двух файлах. Файлы расположены на разных дисках, или имеется двуядерный процессор.

в обоих случаях будет быстрее и проще поискать сначала в одном файле, потом в другом. А вот про шахматы("доооолго думает") - хороший пример.

[pryga]

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

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