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

I>>Мы можем протокол заменить на другой — прочитали, передали дальше, поймали, вычислили, передали дальше, поймали, записали.

S>Какой протокол? Вы что в это слово вкладываете?

Да всё то же, что и всегда.
Ты что, не видишь разницы между инкрементом переменной в памяти и инкрементом переменной в файле? Это ресурсы с разным протоколом доступа. И я показал, что именно там происходит. Что еще тебе надо ?

Вот если вместо асинхронного чтения-записи использовать синхронное, т.е. изменение протокола, все гонки устраняются.

S>>>у нас лежит i+1, но в память еще не записали, переключились на контекст callback'а . Ну прочитает callback значение i, ну и, в чем проблема? i+1 мы еще не опубликовали, это в чьем то стеке\регистре процессора и т.д. А как только i+1 опубликуем, так все последующие callback'и будут читать i+1. Т.е. никакой неконсистентности тут нет. Вполне наличествует сериализуемость.
I>>Это потому, что протокол такой. А если протокол поменять, что я продемонстрировал кодом, то сразу ломается всё подряд.
S>

S>Можно код, который сломает i+=1 при "однопоточном исполнителе"?

Если буквально такой вот код, то никакой, потому что один поток выполняет ровно одну операцию и никто больше на это не влияет. Глаза то раскрой — мои два примера именно про это, только ресурс не переменная в памяти, а внутри файла. Все что делает каждая из задач — инкрементит переменную. Только протокол доступа другой. Какой именно — надо взять, посмотреть, запустить и сравнить результаты двух-трех запусков.

Ты можешь заменить операции с файлом, скажем на такие

async read(): number { return i }

async write(value: number) { i = value }

Собственно, поскольку атомарными будут только чтение переменной и её запись. Все цикл — чтение-инкремент-запись будет неатомарным, а следовательно, несколько параллельных цепочек сломают инвариант.

А вот если убрать async то все стает в норму. Проблема только в том, что теперь циклы будут выполняться последовательно.

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

I>>Мы можем протокол заменить на другой — прочитали, передали дальше, поймали, вычислили, передали дальше, поймали, записали.

S>Какой протокол? Вы что в это слово вкладываете?

Да всё то же, что и всегда.
Ты что, не видишь разницы между инкрементом переменной в памяти и инкрементом переменной в файле? Это ресурсы с разным протоколом доступа. И я показал, что именно там происходит. Что еще тебе надо ?

Вот если вместо асинхронного чтения-записи использовать синхронное, т.е. изменение протокола, все гонки устраняются.

S>>>у нас лежит i+1, но в память еще не записали, переключились на контекст callback'а . Ну прочитает callback значение i, ну и, в чем проблема? i+1 мы еще не опубликовали, это в чьем то стеке\регистре процессора и т.д. А как только i+1 опубликуем, так все последующие callback'и будут читать i+1. Т.е. никакой неконсистентности тут нет. Вполне наличествует сериализуемость.
I>>Это потому, что протокол такой. А если протокол поменять, что я продемонстрировал кодом, то сразу ломается всё подряд.
S>

S>Можно код, который сломает i+=1 при "однопоточном исполнителе"?

Если буквально такой вот код, то никакой, потому что один поток выполняет ровно одну операцию и никто больше на это не влияет. Глаза то раскрой — мои два примера именно про это, только ресурс не переменная в памяти, а внутри файла. Все что делает каждая из задач — инкрементит переменную. Только протокол доступа другой. Какой именно — надо взять, посмотреть, запустить и сравнить результаты двух-трех запусков.

Ты можешь заменить операции с файлом, скажем на такие

async read(): number { return i }

async write(value: number) { i = value }

Собственно, атомарными будут только чтение переменной и её запись, весь цикл — чтение-инкремент-запись будет неатомарным, а следовательно, несколько параллельных цепочек сломают инвариант.

А вот если убрать async то все стает в норму. Проблема только в том, что теперь циклы будут выполняться последовательно.