Потоки vs. процессы

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

Шланг детектед.

>> Дело не столько в производительности, сколько в модели программирования.

Не очень понял идею... дело в архитектуре ПО?

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

Что-то я не о том. Маппинг нитей из юзерспейса на потоки(нити) ядра немного в другой стороне, ага.

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

Ключевыми параметрами, влияющими на выбор той или другой сущности являются: интенсивность использования общей памяти и время жизни сущности.

>P.S. желаю тем, кто использует термин «поток» в смысле «нить», быстрой, но мучительной смерти.

это называется адаптированный перевод. то, что назвали «потоком» гораздо комфортнее в употреблении и в комбинациях с другими словами (многопоточный), что не сказать про «нить» (многонитиевый?).

>Вылезь из своего маленького академического мирка, хотябы в гугл.

google://Нить процесс

Результатов: примерно 2 650 000

google://Поток процесс

Результатов: примерно 226 000 000

ты б сам в гугл сходил бы для начала ;)

ты б сам в гугл сходил бы для начала ;)

google://Тред процесс

Результатов: примерно 880 000 000

И какой вывод можно сделать? Самый правильный термин «Тред»?

Я просто хотел сказать, что термин «нить», это далеко не локальный мем ЛОРа и RSDN. А на статистику гугла полагаться, вещь неблагодарная.

> это называется адаптированный перевод

Устоявщиеся термины/етц, как и названия вещей, в переводах не нуждаются. Тред и тред.

Термин «нить» вообще не соответствует по смыслу тому, что обозначают словом «thread», а вот «поток» вполне себе сойдет...

Ага, и говорить «мультитредный» очень по-русски :)

Термин «нить» вообще не соответствует по смыслу тому, что обозначают словом «thread», а вот «поток» вполне себе сойдет...

Ага, и говорить «мультитредный» очень по-русски :)

Спорить можно до посинения. Вот в свое время пытались некошерное слово «галоши» заменить на кошерное русское «мокроступы». Ну и какой смысл был в этой борьбе? Ъ/не Ъ?

А я вообще только про «калоши» знаю, а что такое «галоши» и чем они от «калош» отличаются - не в курсе :)

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

А я вообще только про «калоши» знаю, а что такое «галоши» и чем они от «калош» отличаются - не в курсе :)

Они отличаются тем, что слово «калоши» является устаревшим, а «галоши» современное. А так это одно и тоже.

См. Большой толковый словарь.

http://www.gramota.ru/slovari/dic/?word=%CA%E0%EB%EE%F8%E8&all=x

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

>что не сказать про «нить» (многонитиевый?).

канатовый!

Зато «общение» потоков настроить проще, в отличие от «общения» процессов.

Пайпы, сокеты и разделяемую память уже отменили?

Вот я и говорю, что потоки синхронизировать проще - достаточно лишь мьютексы ввести. А вот для процессов - всякие shm, flock и т.п.

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

кусок shm и воткнуть туда int с пидом процесса, атомарный cmp_add и простенький spinlock?..

Да ну, фигня. Вы просто IPC не умеете, вот и боитесь.

кусок shm и воткнуть туда int с пидом процесса, атомарный cmp_add и простенький spinlock?..

Да ну, фигня. Вы просто IPC не умеете, вот и боитесь.

Да,черт возьми. Мы боимся. Даже джедаям надо быть осторожными с разделяемой памятью.

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

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

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

Поясню более подробно. Пускай у нас два объекта исполнения A и B, каждый из них работает с некой общей переменной MyValue. Если A и B потоки, то не может быть такой ситуации когда один поток думает, что переменная MyValue находится по одному адресу, а другой думает что по другому. Программисту вообще не надо задумываться над тем по каким адресам находятся переменные, как расположены элементы в структурах и т. д. Он просто работает с ними. Рассогласованность представлений о размещении данных в памяти в принципе невозможна.

Если A и B процессы, то надо самому проследить, чтобы обращение к переменной MyValue в процессе A осуществлялось по тому же самому адресу, что и в процессе B. Чем сложнее структура общих данных, тем сложнее это сделать. Да и локализация ошибок такого рода - не самое приятное занятие.

> Ага, и говорить «мультитредный» очень по-русски :)

Мультитредовый

> Я просто хотел сказать, что термин «нить», это далеко не локальный мем ЛОРа и RSDN.

Как ты думаешь, почему вокруг меня все называют треды тредами?

> кусок shm и воткнуть туда int с пидом процесса, атомарный cmp_add и простенький spinlock?..

Да, спинлок в юзерспейсе - это наше ффсио.

Мультитредовый

Мегарусское слово, пардон за мой бухусскийй...

> > Мультитредовый

Мегарусское слово, пардон за мой бухусскийй...

Скажи, а как ты называешь такие вещи, как прайслисты? Истинно немецким словом прейскурант? Или великорусским ценосписок?

Что делать, если IT & информатика начала развиваться (и продолжает) не в России, и Россия всё ещё догоняющая страна. Нет ничего зазорного в 1) заимствовании 2) тем более нет ничего плохого в продолжении использования устоявщихся терминов.

Ну там же copy-on-write. Если большие изменяемые структуры, то через время у тебя будет много копий.

нет

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

нет

А какие есть варианты? Начнешь крестовый поход?