Паралелност: процеси срещу нишки

Устойчивостта на грешки и скалируемостта са основните предимства на използването на процеси срещу нишки.

Система, която разчита на споделена памет или някакъв друг вид технология, която е достъпна само при използване на нишки, ще бъде безполезна, когато искате да стартирате системата на множество машини. Рано или късно ще трябва да комуникирате между различни процеси.

Когато използвате процеси, вие сте принудени да се справяте с комуникация чрез съобщения, например, това е начинът, по който Erlang обработва комуникацията. Данните не се споделят, така че няма риск от повреда на данните.

Друго предимство на процесите е, че те могат да се сринат и можете да се чувствате относително сигурни, знаейки, че можете просто да ги рестартирате (дори в мрежови хостове). Въпреки това, ако дадена нишка се срине, това може да доведе до срив на целия процес, което може да срине цялото ви приложение. За илюстрация: Ако процес на Erlang се срине, ще загубите само това телефонно обаждане или тази уеб заявка и т.н. Не цялото приложение.

Казвайки всичко това, процесите на OS също имат много недостатъци, които могат да ги направят по-трудни за използване, като факта, че отнема цяла вечност, за да създаде нов процес. Erlang обаче има собствена представа за процесите, които са изключително леки.

С това казано, тази дискусия наистина е тема на изследване. Ако искате да навлезете в повече подробности, можете да дадете статията на Джо Армстронг за устойчиви на грешки системи]1 едно четене обяснява много за Erlang и философията, която го ръководи.

Недостатъкът на използването на процесно-базиран модел е, че той ще бъде по-бавен. Ще трябва да копирате данни между едновременните части на вашата програма.

Недостатъкът на използването на модел, базиран на нишки, е, че вероятно ще го сбъркате. Може да звучи злобно, но е истина-- покажете ми код, базиран на нишки, и аз ще ви покажа грешка. Открих бъгове в код с нишка, който работи "правилно" в продължение на 10 години.

Предимствата от използването на процесно базиран модел са многобройни. Раздялата ви принуждава да мислите от гледна точка на протоколи и официални комуникационни модели, което означава, че е много по-вероятно да го направите правилно. Процесите, които комуникират помежду си, са по-лесни за мащабиране на множество машини. Множеството едновременни процеси позволяват на един процес да се срине, без непременно да се сриват останалите.

Предимството на използването на модел, базиран на нишки, е, че е бърз.

Може да е очевидно кое от двете предпочитам, но в случай че не е: процеси, всеки ден от седмицата и два пъти в неделя. Нишките са твърде трудни: никога не съм срещал някой, който може да напише правилен многонишков код; тези, които твърдят, че могат, обикновено все още не знаят достатъчно за пространството.

В този случай процесите са по-независими един от друг, докато нишките споделят някои ресурси, напр. памет. Но в общия случай нишките са по-леки от процесите.

Процесите на Erlang не са едно и също нещо като процесите на ОС. Erlang процесите са много леки и Erlang може да има много Erlang процеси в рамките на една и съща OS Thread. Вижте Технически защо процесите в Erlang са по-ефективни от Нишки на ОС?

Първо и най-важно, процесите се различават от нишките най-вече по начина, по който се обработва тяхната памет:

Process = n*Thread + memory region  (n>=1)

Процесите имат своя собствена изолирана памет. Процесите могат да имат множество нишки.

Процесите са изолирани един от друг на ниво операционна система. Нишките споделят паметта си с връстниците си в процеса. (Това често е нежелателно. Има библиотеки и методи за отстраняване на това, но това обикновено е изкуствен слой върху нишките на операционната система.)

Паметта е най-важният разпознаващ фактор, тъй като има определени последици:

1. Обменът на данни между процесите е по-бавен, отколкото между нишките. Прекъсването на изолацията на процеса винаги изисква известно участие на извиквания на ядрото и пренасочване на паметта.
2. Нишките са по-леки от процесите. Операционната система трябва да разпредели ресурси и да управлява паметта за всеки процес.
3. Използването на процеси ви дава изолация на паметта и синхронизиране. Често срещаните проблеми с достъпа до споделена между нишки памет не ви засягат. Тъй като трябва да положите специални усилия за споделяне на данни между процеси, най-вероятно ще се синхронизирате автоматично с това.

Използването на процеси ви дава добро (или окончателно) капсулиране. Тъй като комуникацията между процесите изисква специални усилия, ще бъдете принудени да дефинирате чист интерфейс. Добра идея е да отделите определени части от вашето приложение от основния изпълним файл. Може би можете да разделите зависимостите по този начин. напр. Process_RobotAi <-> Process_RobotControl AI ще има значително различни зависимости в сравнение с контролния компонент. Интерфейсът може да е прост: Process_RobotAI --DriveXY--> Process_RobotControl. Може би ще промените платформата на робота. Трябва само да внедрите нов RobotControl изпълним файл с този прост интерфейс. Не е нужно да пипате или дори да прекомпилирате нищо във вашия AI компонент.

Освен това, по същите причини, в повечето случаи ще ускори компилирането.

Редактиране: Само за пълнота безсрамно ще добавя това, което другите ми напомниха: Процесът на срив не води (непременно) до срив на цялото ви приложение.

Общо взето:

1. Искате да създадете нещо силно едновременно или синхронно, като алгоритъм с n>>1 екземпляра, работещи паралелно и споделящи данни, използвайте нишки.
2. Имайте система с множество компоненти, които не се нуждаят от споделяне на данни или алгоритми, нито обменят данни твърде често, използвайте процеси. Ако използвате RPC библиотека за междупроцесна комуникация, вие получавате решение за мрежово разпространение без допълнителни разходи.

1 и 2 са екстремните и безсмислени сценарии, всичко между тях трябва да се реши индивидуално.

За добър (или страхотен) пример за система, която използва силно IPC/RPC, вижте ros.