При сьогоднішніх тенденціях на ринку процесорів доводиться задумуватися над оптимізацію коду під багатоядрові процесори. (запозичено кількома постами раніше отут: http://lsdc.org.ua/content/фактор-страху-багатоядровість)

Проблема існує і існує безліч дисертацій, реалізацій, концепцій та традицій написання безстрашного(надалі буду вживати це слово для означення коду, що не боїться паралелізації) коду. На мою скромну думку, вся проблема є дуже роздутою, здебільшого завдяки найпоширенішій на сьогоднішній день парадигмі імперативного програмування.

Звідки береться страх до паралелізації обчислень? Ключова теза - дані, на які вказують мої вказівники/змінні можуть змінитися в під час виконання якогось паралельного процесу. В імперативному коді ви не можете бути впевненими, що дані, котрі ви обробляєте(точніше проводите атомарні зміни) не зміняться паралельним процесом. Для цього було введено багато складних технік, зокрема мутексування та блокування окремих кавалків пам'яті, але для простих смертних такий підхід є неприйнятно важким для вивчення.

Всі ці проблеми зникають з зміною імперативної парадигми на функціональну. Простіше кажучи - не діліться ні з ким пам'яттю і в вас не буде проблем паралелізації. Отак просто.

Як тоді обмінюватися даними між паралельними процесами? MPI - message passing interface. Кожен процес має скриньку в яку інші процеси можуть скидати повідомлення про зміну свого(чи ініціювання зміни чужого) стану.

Власне кажучи на цьому можна і закінчити. Функціональність та пересилання повідомленнь повністю реалізують платформу для розробки абсолютно безстрашного коду.

Програш такої концепції в швидкості програм, але за рахунок прозорої кластеризації та абстракції методу пересилання повідомлень (це може бути не лише внутрішня система, але і писання в порти, пересилання через мережу) ви збережете собі сотні годин розробки та дебагу і позбавитеся головного болю від того, що якийсь нуб забув викликати lock.release()

P.S. знову ж таки, весь пост написаний з власного досвіду писання програм на Erlang'у. гугл знає решту ;)