Kobezzza. База в программировании

🔵 ПОТОКИ И ПАМЯТЬ В JS. ЧАСТЬ 2.



Всем привет! Пишу обещанную ранее статью про общую разделяемую между потоками структуру данных в JS. Но для начала давайте разберемся зачем нам вообще это может быть нужно. Дело в том, что бывают задачи, когда с одними и теми же данными работает много потоков исполнения.



Например, мы пишем программу для рендеринга изображения с расчётом реалистичного света и отражений. Такая программа весьма затратна для CPU, но её можно легко распараллеливать на несколько выполняемых задач. И вот это как раз то самое место, где нам понадобиться разделяемая память, т. к. копирование при передаче может быть слишком избыточным, а передача по владению не позволит потокам вести работу одновременно.



Как же это решается в JS?



В JS есть особая структура данных именуемая SharedArrayBuffer. С виду эта структура очень похожа на обычный ArrayBuffer, т. е. для работы с ней нам необходимо сделать проекцию с помощью одного из типизированных конструкторов.

const buffer = new SharedArrayBuffer(1024);

const arr = new Uint8Array(buffer);



arr[0] = 1;

console.log(arr[0]);

Также, для работы в браузере этой структуры, у целевого документа должны быть установлены специальные HTTP заголовки.

Cross-Origin-Opener-Policy: same-origin

Cross-Origin-Embedder-Policy: require-corp или credentialless.

Эти заголовки нужны для предотвращения атак типа Spectre, которые взбудоражили весь мир в 2018 году. Однако, для использования в Node.js никакие заголовки или флаги не нужны.



Окей, значит передавая такой вот буфер из потока в поток, мы можем читать и писать в него одновременно? Разве это не может привести к гонкам? 🤔



Ну, если у нас возникнет ситуация, что есть хотя бы один писатель и читатель одной и той же ячейки памяти из разных потоков, то у нас возникнет гонка. И это важно понимать, что сами по себе разделяемые данные, как правило, не приводят к гонкам - проблемы начинаются, когда кто-то начинаем менять эти самые данные.



Но в случае с потоками все еще интереснее, т.к. результат многих операций становиться непредсказуемым. Например, что если делать инкремент числа одновременно из нескольких потоков?



И тут ситуаций масса: число может увеличиться, но возвращаемый результат будет не тем, что мы ожидаем; число увеличится, но на меньшее количество... Почему такое происходит?



Все дело в атомарности операций: то, что для нас может казаться атомарным, под капотом может состоять из нескольких инструкций. А теперь добавьте к этому, что наши потоки могут исполняться одновременно. И, наконец, код которым мы пишем, может исполняться не в том порядке, в каком мы его написали. Звучит странно?



Но правда в том, что компиляторы и процессоры могут менять порядок выполнения инструкций, чтобы эффективнее использовать ресурсы компьютера. И если в обычным однопоточном коде, это не может привести к каким-либо последствиям, то при работе уже нескольких потоков никаких гарантий нет.



😨 Все это звучит страшно?



Ну так и есть. Вообще многопоточное программирование - это тема, которой можно посвятить не одну книгу или курс. Можно рассказать про модель памяти; блокировки и синхронизации; структуры данных по типу RWLock или Mutex и многое другое.



Но мы же говорим про JS и в JS у нас есть низкоуровневый примитив Atomics, который предоставляет API как для атомарного обновления данных в SharedArrayBuffer, так и для создания блокировок потоков. А также вводит контракт, что любой код написанный выше атомика точно выполнится раньше, а тот, что ниже - позже.



Приведу простой пример и буду на сегодня закругляться.

const buffer = new SharedArrayBuffer(16);

const arr = new Uint8Array(buffer);



console.log(Atomics.store(arr, 0, 2)); // 2

console.log(Atomics.load(arr, 0));     // 2

На первый взгляд все просто, но, вообще, Atomics - это базовый кирпичик, из которого строятся уже более могущественные примитивы.



Более подробно я разберу его использование в своём следующем посте. Но если тебе интересна тема параллельных вычислений в JS, то приглашаю на свой авторский курс CS во Frontend - https://kobezzza.ru/, где этой теме посвящен отдельный цикл лекций.