Чому я повинен знати одночасне програмування?

Одночасне програмування мені досить складно: навіть перегляд основного слайда мені здається складним. Це здається таким абстрактним.

Які переваги добре знати поняття одночасного програмування? Чи допоможе це мені в регулярному послідовному програмуванні? Я знаю, є задоволення від розуміння того, як працюють наші програми, але що ще?

Ось швидка і проста мотивація: якщо ви хочете кодувати що-небудь, крім найменшої, найслабшої системи, ви будете писати одночасний код.

Хочете написати для хмари? Обчислювальні екземпляри у хмарі невеликі. Ви не отримуєте великих, ви отримуєте багато маленьких. Раптом ваш маленький веб-додаток одночасно додаток. Якщо ви це добре спроектували, ви можете просто кинутись на більше серверів, коли ви завойовуєте клієнтів. Крім того, ви повинні дізнатися, як у вашому екземплярі прив'язується середнє навантаження.

Гаразд, ви хочете написати додатки для настільних ПК? У всіх є процесор з подвійним або більш ядерним процесором. За винятком найменш дорогих машин. А люди з найменш дорогими машинами, напевно, не збираються розпрощатися за вашим дорогим програмним забезпеченням, чи не так?

Можливо, ви хочете займатися мобільною розробкою? Гей, iPhone 4S має двоядерний процесор. Решта не відстають.

Відео ігри? Xbox 360 є багатопроцесорною системою, а PS3 Sony - це, по суті, багатоядерна система.

Ви просто не можете піти від одночасного програмування, якщо не працюєте над крихітними простими проблемами.

Оновлення 2016 року : поточна ітерація Raspberry Pi в розмірі $ 35 побудована навколо чотирьохядерної системи на чіпі, призначеному для стільникових телефонів. Драматичний прогрес AI був досягнутий частково завдяки наявності високоякісних відеокарт як паралельних обчислювальних механізмів.

З 1970 по 2002 рік процесори збільшувались удвічі в швидкості приблизно кожні 18 місяців. Отже, як програміст, все, що вам потрібно було, це почекати, і ваша програма піде швидше. Проблема полягає в тому, що близько 2002 року правила змінилися. Тепер вони не роблять більших швидких процесорів, вони роблять менші повільні процесори, але розбивають їх у групи. На комп'ютері, на якому я зараз працюю, є 4 ядра, а мікросхеми до 8 ядер (і 4 потоки на ядро) існують. Незабаром у нас з’являться чіпи з набагато більшою кількістю ядер.

Отже, якщо ви пишете програму, яка зовсім не є одночасною, ви виявите, що ви використовуєте 1 ядро ​​або нитку, але решта CPU сидить там і нічого не робить. Тож якщо у вас 16 ядер, 1 буде запускати вашу програму, а інші 15 сидять там!

Проблема з одночасністю полягає в тому, що вона не є детермінованою. Що означає, що ви точно не знаєте, в якому порядку будуть виконуватись різні потоки. Традиційно програмісти намагаються вирішити це за допомогою замків тощо. Це призвело до LOT болю. Наявність певної форми змінних станів, що більш ніж одна нитка може вільно отримувати доступ, часто є формулою для болю та хвороб!

З пізньої тенденції слід переходити до функціональних мов, які жорстко контролюють стан, що змінюється. Є два основні способи, якими функціональні мови керують паралельністю. Перший - за допомогою передачі повідомлень. Найкраще це показує Ерланг. У Ерланг взагалі немає загального стану між процесами. Вони спілкуються не діленням пам’яті, а моїми переданими повідомленнями. Це має мати сенс для вас, як ми це робимо зараз. Я передаю вам цю інформацію, надсилаючи вам повідомлення, а не ви запам'ятовуєте його з мого мозку! Перейшовши на повідомлення, що передає більшість помилок блокування, просто відійдіть. Крім того, повідомлення можуть передаватися по мережі, а також в межах одного вузла.

Інший метод - STM, який розшифровується як пам'ять транскрипції програмного забезпечення, це присутні в clojure та Haskell (та інших). У STM пам'ять поділяється, але зміни можуть бути здійснені лише через транзакцію. Оскільки в Базі даних люди зрозуміли, що все це вийшло в 1970-х, досить легко переконатися, що ми все зрозуміємо.

Насправді я трохи спростив, Clojure і Haskell можуть обидва робити передачу повідомлень, а Erlang може робити STM.

Відмова Я є автором програми веб-служб програмування з Erlang , яка буде випущена в ранньому випуску протягом найближчих кількох тижнів.

Тому що одночасність може підірватися вам на обличчя, коли ви цього найменше очікуєте ...

Перше правило одночасного програмування - "Важко". Друге правило паралельного програмування - "Це. Є. Складно" .. !!

Якщо серйозно, то є два загальних підходу до паралельного програмування, багатопотокової та багатообробної обробки. Багатоопрацювання є найпростішим для розуміння, оскільки це просто означає наявність декількох екземплярів процесу, який працює для виконання завдання. Це досить просто зробити в системах на базі Unix за допомогою дзвінків до роздрібнення / приєднання, але не так просто в системах Windows.

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

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

Недоліком є ​​те, що ви повинні почати думати про те, як ви розділите додаток на невеликі частини, які можна запустити на різні теми. Це набагато важче, ніж це звучить. Крім того, дуже одночасні рішення можуть бути незручними для одиничного тестування, оскільки порядок виконання є менш детермінованим.

У наші дні більшість мов постачаються з абстракцією над більшістю паралельних примітивів, щоб полегшити життя. Наприклад,. NET 4 поставляється з бібліотекою завдань паралельних завдань, яка полегшує життя. У землі Java вони отримали пакет Concurrency .

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

Працюючи з PHP, я робив речі старомодним способом, і найкращий час, який я отримав після кількох годин роботи, призвів до ~ 120 секунд для виконання певного тесту (багато запитів + ​​затримка мережі + відсутність асинхронізації)

Але цього було майже недостатньо в порівнянні з тим, що мені потрібно, і після того, як невдало провалився багатопроцесорний PHP, я перейшов на Python.

Через кілька годин у мене з’явився запущений багатопроцесорний сценарій Python, який запустився за 20 секунд, а після трохи сповнення з таймаутами та ні. ниток для використання, я знизив його до ~ 10 секунд .

Це було для веб-сайту, написаного 100% на PHP, за винятком одного, 100-рядкового сценарію Python. І вся справа працює ідеально.

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

Удачі та щасливого кодування!

PS: Я не намагаюся бити PHP, але PHP просто не був правильним інструментом для роботи.

PS2: Знання нової технології або нового способу роботи може відкрити двері до цілого нового світу можливостей.

Якщо ви робите будь-які веб-розробки, паралельність вступає в силу, принаймні, для більшості мов. Наприклад, я використовую весну для розробки веб-сторінок, і кожен новий запит надходить як власна нитка. Отже, якщо будь-який запит закінчує доступ до спільного об'єкта, де стан змінної змінної може бути змінено, паралельність є дуже важливим фактором і її слід враховувати. Якщо цього немає, то дані можна редагувати непередбачуваними способами, і це може призвести до пошкодження даних. Не важливо знати кожну останню деталь про одночасність, але вивчити деталі за раз важливо, щоб краще зрозуміти програмування веб-додатків, якщо ви працюєте на додатках для настільних ПК, можливо, це не так важливо, якщо вам не потрібно запускати кілька потоків

Дізнайтеся про розуміння операційних систем. Читання вихідного коду планувальників та драйверів пристроїв допоможе; вони безумовно одночасні.