Які недоліки зробити багатопотокову реалізацію JavaScript? [зачинено]

Я працював над багатопотоковою реалізацією JavaScript протягом минулого тижня. У мене є доказ концепції, зробленої на C ++ за допомогою JavaScriptCore та boost.

Архітектура проста: коли час закінчення оцінювання основного сценарію він запускається та приєднується до пулу потоків, який починає вибирати завдання із спільної черги пріоритетів, якщо дві задачі намагаються отримати доступ до змінної одночасно, вона позначається атомною, і вони претендують на доступ .

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

Спочатку я мав місце в реальному застосуванні кореневої програми (використовуючи прискорений контекст), але мені довелося її скинути (JavaScriptCore педантично стосується стека), і я не хотів ризикувати їх гнівом, тому вирішив проти згадки про це.

Що ти думаєш? Чи призначений JavaScript бути однопоточним і чи його слід залишати в спокої? Чому всі проти ідеї одночасного виконання JavaScript?

Редагувати: Проект зараз на GitHub , експериментуйте з ним самостійно і дайте мені знати, що ви думаєте.

Далі представлена ​​картина обіцянок, що виконуються на всіх ядрах процесора паралельно без суперечок:

1) Багатопоточна редакція надзвичайно важка, і, на жаль, те, що ви представили цю ідею дотепер, означає, що ви сильно занижуєте, наскільки це важко.

На даний момент це здається, що ви просто "додаєте теми" до мови та переживаєте, як зробити її правильнішою та ефективнішою пізніше. Зокрема:

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

Додавання потоків до Javascript без "рішення проблеми синхронізації" було б як додавання цілих чисел до Javascript без "рішення проблеми додавання". Це настільки принципово для природи проблеми, що в принципі немає сенсу навіть обговорювати, чи варто багатопотокове читання додавати без конкретного рішення на увазі, як би сильно ми цього не хотіли.

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

Мені також не зрозуміло, чи намагаєтесь ви зберегти теми прихованими від програміста node.js, чи плануєте викрити їх у якийсь момент, ефективно створивши новий діалект Javascript для багатопотокового програмування. Обидва варіанти є потенційно цікавими, але здається, ви ще навіть не вирішили, на який саме ви прагнете.

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

Напевно, тому люди не сприймають вас серйозно.

2) Простота та надійність циклу одиночних подій є величезною перевагою.

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

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

3) Javascript вже підтримує "фонові потоки" (WebWorkers) та асинхронне програмування, не піддаючи програмісту безпосередньо управління потоками.

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

Чи є у вас якісь конкретні випадки використання на увазі, що ці функції не вирішуються і що програмісти Javascript хочуть вирішити? Якщо так, то було б хорошою ідеєю представити ваш багатопотоковий node.js в контексті конкретного випадку використання.

PS Що переконало б мене спробувати перейти до багатопотокової реалізації node.js?

Напишіть нетривіальну програму в Javascript / node.js, яку, на вашу думку, виграєте від справжньої багатопотокової роботи. Зробіть тести на ефективність для цієї зразкової програми у звичайному вузлі та вашому багатопотоковому вузлі. Покажіть мені, що ваша версія значно покращує продуктивність, швидкість реагування та використання декількох ядер, не вводячи жодних помилок чи нестабільності.

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

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

Я б сказав, що це тому, що інваріанти не завжди виражаються значенням однієї змінної, а "однієї змінної" недостатньо, щоб бути загальним випадком блокування. Наприклад, уявіть, що ми маємо інваріант a+b = 0(баланс банку з двома рахунками). Дві функції нижче забезпечують, що інваріант завжди утримується в кінці кожної функції (одиниця виконання в однопотоковому JS).

function withdraw(v) {
  a -= v;
  b += v;
}
function deposit(v) {
  b -= v;
  a += v;
}

Тепер у вашому багатопотоковому світі, що відбувається , коли два потоки виконання , withdrawі depositв той же час? Дякую, Мерфі ...

(У вас може бути код, який розглядає + = і - = спеціально, але це не допомагає. У якийсь момент у вас буде функція локального стану, і жодний спосіб одночасно "заблокувати" дві змінні ваш інваріант не буде бути порушеним.)

EDIT: Якщо ваш код семантично еквівалентний коду Go за адресою https://gist.github.com/thriqon/f94c10a45b7e0bf656781b0f4a07292a , мій коментар точний ;-)

Десятиліття тому Брендан Ейх (винахідник JavaScript) написав есе під назвою Threads Suck , що, безумовно, є одним з небагатьох канонічних документів міфології дизайну JavaScript.

Чи правильно це - інше питання, але я думаю, що це мало великий вплив на те, як спільнота JavaScript думає про одночасність.

Атомний доступ не перетворюється на безпечну поведінку.

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

Javascript з однієї нитки був з ниткими та пісочницями, і весь код записується з урахуванням цих припущень.

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

Чи буде ваш підхід значно покращити ефективність роботи?

Сумнівні. Вам справді потрібно це довести.

Чи буде ваш підхід полегшити / швидше писати код?

Безумовно, ні, багатопотоковий код набагато складніше отримати правильно, ніж однопотоковий код.

Чи буде ваш підхід більш надійним?

Тупики, умови перегонів тощо - це кошмар, який потрібно виправити.

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

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

Це потрібно. Відсутність механізму сумісності низького рівня в вузлі js обмежує його застосування в таких галузях, як математика та біоінформатика тощо. Крім того, паралельність з потоками не обов'язково суперечить моделі дефіциту за замовчуванням, що використовується у вузлі. Існує добре відома семантика для нанизування різьби в середовищі з основним циклом подій, таких як фреймворки ui (та nodejs), і вони, безумовно, надмірно складні для більшості ситуацій, у яких все ще є дійсне використання.

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

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

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