Здравствуйте, vdimas, Вы писали:

V>ОМГ. ))
V>Я предпочитаю озвучить ТЗ, потому что это иначе спекуляции.
Какое ТЗ? Речь идёт о целом классе задач, у которых есть характерные общие черты.

V>Потому как иначе получается, что ты тоже умудрился много чего проигнорировать, например, то, что сама операция SetRemoteResource должна быть атомарной, например, для случая, когда тип I представлен значением, которое не записывается в своё хранилище за одну операцию процессора. Как эту атомарность обеспечивать будем в случае жабасрипта?
Ну, если у нас есть готовое решение для обеспечения атомарности всего блока, то уж наверное можно его применить и к отдельной операции, нет?

V>Итак. Есть задача писать в файл некие сообщения. Пусть сообщение представлено типом-кодом и телом, где разметка тела полностью определяется типом сообщения, т.е. как-то так: {typeCode1:8, field1:16, field2:64 }, { typecode2:8, field:128 } и т.д., где N в записи ':N' означает некую разрядность в разметке сообщений и используется исключительно в кач-ве примера наличия разных разметок разных сообщений.

V>Пусть у нас есть несколько логических потоков в жабаскрипте (т.е. несколько async-методов), в которых мы генерируем и записываем в файл эти сообщения "одновременно". Требуется организовать процесс записи файла так, чтобы каждое сообщение было записано в файл целиком, кароч, чтобы в результирующем файле у нас не возникла "каша" из перекрывающихся тел сообщений.

V>Вопрос, нужны ли в случае жабасрипта критические секции, мьютексы и т.д. для этой задачи?
Всё зависит от того, есть ли у нас гарантия единственности системного потока, в котором бегут эти логические потоки. Потому что если вдруг VM начала использовать N потоков (или если мы тупо запустили 2 инстанса VM на одной машине), то без примитивов мы получаем гарантию мусора.

V>Это работает и в кооперативной. Причем, давний спор с Ikemefula был именно относительно того, что именно в кооперативной многозадачности можно обходиться без мьютексов, если известно, что все кооперативные "одновременные" потоки, обращающиеся к одному и тому же ресурсу, сидят поверх одного потока ОС, как в жабаскрипте.
Да, это так. Но вот эту уверенность лучше основывать на чём-то надёжнее, чем "я пока ни разу такого не видел". Потому что я видел много "многопоточного" кода, который уверенно работал ровно до момента запуска на многоядерной машине.

V>Если требуется некая транзакционность при работе с удалённым ресурсом, то, в зависимости от вида транзакционности, обеспечиваемой удалённым ресурсом, мы можем нарваться на идентичные сценарии даже в твоей "кооперативной" многозадачности, где остальные таски, зависимые от этого ресурса, в любом случае будут ждать ресурс. Ууупс?
Ну, для этого придётся специально постараться. Но это будет ожидаемым поведением — важное выделено. В наивной реализации блокируюшего IO заблокируется вообще весь мир, а не только зависимые таски.

V>И да. Я лишь настаивал на том, что кооперативную многозадачность можно выразить через вытесняющую, где весь код от yield до yield обложен парой disable interruptions / enable interruptions. И предлагаю пользоваться этим знанием, а не показательно его игнорить, впадая вот в такую ересь.
Выразить можно всё, что угодно. Просто обычно вытесняющая многозадачность — адски дорогая. Поэтому лучше иметь кооперативную многозадачность с примитивами синхронизации.