В каких случаях удобнее использовать processes , в каких удобнее threads?

Привет! Экзаменационный вопрос:

show a real case
example in which you would choose processes, and another in which you would choose threads

---------------------------------------------------------------------------------------------------------------------------------------------

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

А вот в каких случаях удобнее и предпочтительнее использовать processess. Напишите, пожалуйста, реальные примеры с жизни + объяснение.

++ если есть, что добавить к threads - добавляйте!

Век живи, век учись.

0

https://www.cyberforum.ru/blogs/18334/blog310.html там по сути полезным является только пример с процессами

3

У потоков общие ресурсы и общая область памяти, а у процессов нет.

1

Про процессы.

Если нужно обеспечить отказоустойчивость или изолированность. Разрушение одного процесса не приводит к разрушению другого. Например, софт обеспечивает вещание нескольких медиа-каналов по сети. Он состоит из одного центрального менеджера, который запускает каждый канал в отдельном процессе и следит за его работой. Критический сбой в любом из процессов не приводит к фатальному сбою в центральном менеджере и может быть программно обработан.

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

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

Добавлено через 4 минуты
Ещё вспомнил экзотик из жизни. Была закрытая библиотека, которая способна работать только в 32х битном режиме. Нужно было прикрутить её к 64х битному процессу. Что бы сделать подобное пришлось запустить отдельный 32х битный процесс, который работал с этой библиотекой. А 64х битный процесс уже работал с 32х битным процессом.

2

Ygg, Alexei55555, Evg,
Спасибо!

А мой пример с threads - правильный ? Или еще могу что-то добавить в деталях.

Заранее Спасибо!

0

Сообщение от robben_55 А мой пример с threads - правильный ?

Если для экзамена, то правильный

Если по-настоящему, то надо спрашивать специалистов. У web-сервера очень короткий сеанс: получил соединение, выплюнул данные и завершил работу. В таких условиях, возможно, без потоков будет работать быстрее. Но в современном web'е уже может быть всё и не так просто

Добавлено через 2 минуты

Сообщение от Evg Если для экзамена, то правильный

Правда вывод не совсем корректно сделан. Многопоточный сервер в первую очередь нужен ради того, чтобы на многоядерном процессоре работать эффективно. Чем больше ядер, тем лучше работает, а от программиста никаких дополнительных усилий не требуется. А "не тупит и успевает обрабатывать запросы" от многопоточности мало зависит. Сетевые соединения всё равно операционной системой обрабатываются последовательно. Да и чтение файлов с диска условно последовательно. Это одни из узких мест, и многопоточность там не особенно и спасает

1

Часть текста с книги Operating Systems by Silberschatz.

It is generally more efficient to use one process that contains multiple threads. If the web-server process is
multithreaded, the server will create a separate thread that listens for client
requests. When a request is made, rather than creating another process, the
server creates a new thread to service the request and resume listening for
additional requests.

---------------------------------------------------------------------------------------------------------------------------

Я только начал изучать эти вопросы. Уважаемые форумчане, правильно ли тут написано ?
С уважением.

Добавлено через 1 минуту
+ а ядро операционной системы использует threads ?
могу ли я так же включить его в свой вопрос?

0

Здесь сказано, что после получения запроса от клиента, создаётся отдельный поток, который этот запрос обработает и выплюнет ответ клиенту (to service the request). Вероятно, подразумевается, что сам процесс исполнения запроса является длительным, т.е. непосредственное время обработки запроса сильно превышает время, требуемое на создание потока. В каком-то смысле это помогает "не тупить и успевать обрабатывать запросы"

Т.е. я понял, что тут имел в виду автор, но по простому объяснить это сложно. Но совсем вкратце - так сделано НЕ для того, как я это писал в конце поста #6. А именно ради того, чтобы не тупить. В ссылке из поста #2 почитай раздел 2.2. Здесь необходимость вынесения работы в поток продиктована примерно такими же соображениями

Добавлено через 2 минуты

Сообщение от robben_55 + а ядро операционной системы использует threads ?

Кратко: нет. Более развёрнуто: вопрос поставлен некорректно. Ядро создаёт возможность для работы потоков. Объяснять сложно и долго. Можешь попробовать почитать тут https://www.cyberforum.ru/blog... g4913.html, есть некоторая вероятность, что после этого начнёшь лучше понимать

1

Finally, most operating-system kernels are now multithreaded. Several
threads operate in the kernel, and each thread performs a specific task, such
as managing devices, managing memory, or interrupt handling. For example,
Solaris has a set of threads in the kernel specifically for interrupt handling;
Linux uses a kernel thread for managing the amount of free memory in the
system.

Опять-таки та же книга.


Я прочитал ваш FAQ, но ничего не понял.
Если не трудно, тут можете написать самые тривиальные примеры, когда предпочтительнее использовать threads, а когда processes. Если не составит труда напишите тут, пожалуйста. Если да - благодарен вам за попытки мне помочь.

0

Сообщение от robben_55 Finally, most operating-system kernels are now multithreaded. Several threads operate in the kernel, and each thread performs a specific task, such as managing devices, managing memory, or interrupt handling. For example, Solaris has a set of threads in the kernel specifically for interrupt handling; Linux uses a kernel thread for managing the amount of free memory in the system.

Я не знаю, что это, но это явно какая-то сильно внутренняя кухня ядра операционной системы. К тем потокам, которые используются на пользовательском уровне, внутриядерные потоки отношения не имеют. Это просто однофамильцы. Возможно, что внутри ядра они даже называются не thread, а как-то иначе, просто автор для простоты назвал их словом thread

Сообщение от robben_55 Если не трудно, тут можете написать самые тривиальные примеры, когда предпочтительнее использовать threads, а когда processes

См. пост #2 и пост #4

1

Ygg, Уважаемый.

Ваш пример про софт , который вещает каналы.

Например может ли это быть программа для IPTV ?
Например сама программа когда запускается - она и является процессом+ а ещё когда мы хотим смотреть HBO TV например, чтобы мы могли смотреть этот канал , программа создаёт новый процесс , чтобы показывать нам данный канал ? И даже если ошибка в трансляции идёт от сервера HBO , данный процесс запустивший Канал для просмотра hbo можно закрыть (то есть нажав на крестик) и данная проблема в трансляции никак не перейдёт на главный процесс , так так процессы изолированы друг от друга ?

0

Сообщение от robben_55 Например может ли это быть программа для IPTV ?

Я описал реализацию серверной части IP-сервера от Elecard. Там не видео по запросу, а постоянно работающие "живые" широковещательные каналы. Желающие подключаются к каналам и смотрят их. Проблемы клиентов, их подключение или отключение не влияет на работу серверной части. Серверная часть работает всегда в соответствии с заданным расписанием.

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

Потоки.

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

Оконные программы требуют постоянного контроля действий пользователя: движение мышью, нажатие кнопок клавиатуры, перерисовка окна. Если вдруг нужно выполнить какую-то очень длительную операцию, то лучше не делать этого в интерфейсном потоке, так как программа надолго "повиснет". В таком случае длительную задачу запускают в отдельном потоке, а интерфейсный поток используют для отображения прогресса и взаимодействия с пользователем.

Некоторые задачи можно разбить на части, но нельзя распараллелить. Каждая следующая часть требует результатов полученных предыдущей частью. Если такие задачи подразумевают потоковую обработку данных (новые данные постоянно поступают для обработки), то можно организовать конвейер. Все части задачи будут выполняться последовательно, но каждая в своём потоке. Это позволяет параллельно выполнять первую часть для новых данных, вторую часть для предыдущих данных и т.д. Многие медиа-плееры построены на данном принципе. Одна часть читает файлы, вторая декодирует, третья как-то обрабатывает, четвёртая выводит на экран.

0

Сообщение от robben_55 чтобы мы могли смотреть этот канал , программа создаёт новый процесс , чтобы показывать нам данный канал ?

Я если честно сильно не знаком с технологиями IPTV, но например, как работает кабельное... На каждое соединение клиента не нужен отдельный процесс, иначе серверное оборудование просто захлебнется, со стороны сервера просто выполняется широковещательная рассылка, а приемники просто принимают пакеты и декодируют их в соответствии с протоколом. Что значит широковещательная рассылка, это рассылка не конкретным клиентам в сети, а всем и поддерживать связь между клиентом и сервером не нужно. Т.е. серверу "наплевать" сколько клиентов его пакеты принимают, его задача только отправлять эти пакеты.
По поводу IPTV я не знаю, но как минимум всё идет по протоколу UDP - это когда нет постоянного подтверждения между клиентом и сервером о успешности доставки пакета. Например в TCP когда клиент не принял пакет, он направляет серверу уведомление об этом, и сервер заново высылает пропущенные пакеты, и так же со стороны сервера, если подтверждение от клиента не пришло, то он опять же заново высылает пакеты. Вот в таком виде соединений, лучше использовать процессы.
А потоки используют для ускорений вычислений и для работы с общей памятью, когда потоку нет смысла жить отдельно от процесса и это по сути одно целое, только разбитое по ядрам ЦП.

Добавлено через 6 минут
Кстати, Google chrome, насколько мне известно, на каждую вкладку создает отдельный процесс, как раз для того, что бы не убивать весь браузер или он не тормозил, когда одна из вкладок подвисла

0

Сообщение от robben_55 It is generally more efficient to use one process that contains multiple threads. If the web-server process is multithreaded, the server will create a separate thread that listens for client requests. When a request is made, rather than creating another process, the server creates a new thread to service the request and resume listening for additional requests.

Сообщение от robben_55 Например, в каком случае я выберу threads - веб сервер.

Сообщение от robben_55 А мой пример с threads - правильный ?

Ваш пример соответвствует написанному в книге. Это так только на системах, где потоки значительно "легче" процессов. Линукс, напр. к таким не относится. А между прочим, именно на нем крутится львиная доля веб-серверов.

Сообщение от robben_55 Например, в каком случае я выберу threads - веб сервер.

В случае веб сервера, вам правильный ход мысли указал Evg.
Апач, напр. испльзует отдельные процессы на Линуксе и потоки на Венде для каждого соединения. Это его делает тормозным. Нджинкс, напротив, использует один мастер-процесс для всех соединений и быстро передает его на обработку рабочим процессам (обычно по количеству ядер).

Сообщение от robben_55 Если не трудно, тут можете написать самые тривиальные примеры

Ваше вам уже написали. Процессы - если нужна изоляция, напр. вкладки Хромиума. Потоки, если нужен параллельный доступ к одной области данных.

1

gng,
Решения с потоками по идее должно быть в целом шустрее чем решение с процессами и в линуксе тоже. Например при переключении контекста если с одного ядра слезет задача сервера, и на это же ядро залезет другая задача этого же сервера, то в случае с процессами будут страдать кеши, а с потоками такой проблемы нет потому что память то одна. А у процессов - каждому отдельный участок памяти. Но с процессами иногда надежнее.

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

1

Сообщение от Undisputed Насчёт нгинкс они вроде отказались от мастер процесса который раздаёт соединения на обработку, вместо этого каждый процесс теперь может принимать соединения (каждый процесс садится на одинаковый порт за счёт so_reuseport)

Посмотрел. Появилась опция конфигурации reuseport. По умолчанию у меня на nginx 1.10 не включена. Попробую включить для интереса. Спасибо.

0

gng,
Ок, не за что.
https://m.habr.com/ru/post/259403/
Если интересно тут подробно расписано, с какой версии это работает. Бенчмарки тоже есть

0

Сообщение от Undisputed а с потоками такой проблемы нет потому что память то одна

У них только общая память для глобальных данных. Если потоки будут выделять память через malloc, то это тоже будет разная память. Конкретно в случае web-сервера почти наверняка так и будет. А в случае какой-нибудь счётной задачи - почти наверняка НЕ будет. Правда в последнем случае данные скорее всего будут размещаться в стеке, а потому с точки зрения кэша тоже нет никакой разницы по сравнению с процессами

0

Evg,
ну зависит от того как вообще организованы данные.
наличие маллок ведь != разная память
множество потоков вполне себе может использовать один и тот же пул

0

Сообщение от Undisputed множество потоков вполне себе может использовать один и тот же пул

Конечно, может. Но в случае web-сервера поток выделяется для того, чтобы выполнить условно независимую задачу. Это один из способов применения потока. Я так понимаю, что в посте #15 ты говорил именно о web-сервере

Когда речь идёт о кэше, то речь об одних и тех же данных можно вести только тогда, когда они действительно одни и те же с точностью до cache-line байт (величина порядка 64 байт). И только тогда, когда потоки долбятся в один и тот же маленький фрагмент, можно говорить о более эффективном использовании кэша. Как только потоки начали долбиться в соседние фрагменты (пусть и выделенные внутри одного пула памяти), то тут уже два физически разных cache-line'а, а следовательно, уже нет принципиальной разницы между потоками и процессами с точки зрения кэша

0