>ну вообще-то для параллельного программирования используют именно нити (pthread.h) в адресном пространстве
>одного процесса, то есть просто параллельные функции http://www.opengroup.org/onlinepubs/007908799/xsh/pthread.h....
>
>клонирование процессов с помощью fork() используется в основном для запуска иного процесса
>с exec() как раз таки я и хотел скахать что применение нитей (posix_threads) -- сейчас используют НЕ для увеличения производительности. а только для усложнения логики программы (например сделать некий процесс асинхронным, в случае если его компонент УЖЕ имеет только синхронный интерфейс. или наоборот)..
..раньше -- да -- Нити (pthreads) использовали для увеличения производительности.. (было дело -- не спорю)
....а сейчас -- принято использовать сборшики мусора (сложные модели данных с цеклическими зависимостями -- как могут обойтись без сборщика мусора?) , который блокируют сразу ВСЕ нити (одного процесса) при своей деятельности.
....также принято использовать и другие всевозможные мьютексные блокировщики.. другими словами в сложных много-нитевых программах -- в текущий момент времени ЗАЧАСТУЮ выполняется только одна нить!
а всё это -- потомучто нити общаются между собой через общие данные (а не через каналы (pipe) ) , поэтому и происходится использовать постоянную синхронизация через блокировки.
(ято конешно понимаю что у каждого низкоуровневого компонента/класса -- может быть свой независимой мьютекс (или несколько) . но чем больше разных мьютексов -- тем больше вероятность неправильной архитектуры приложения и врезультате чего -- появления вероятности "Взаимоблокировки" ("Deadlock") . да и с множеством мьютексами -- не факт что мы не будем постоянно вызывать блокировку многочисленных Нитей (pthreads) в тех или иных местах программы...)
выход из решения проблемы -- процессы! (ктото выше -- называл слово "потоки". но дабы не путать "потоки" и с "потоками <iostreams>" не буду употреблять это слово)
процессы работают каждый в своём адресном пространстве и не блокируются изза постоянных блокировок нитей других процессов. а обмен данными через каналы (pipe) который ещё и обладает некоторым буфером -- НЕ ВЫЗЫВАЕТ излишние блокировки при обмене состоянием!
