Для тех, кто смеется над JavaScript - Компьютерные священные войны

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

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

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

I>>>

I>>>async read(): number { return i }

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

S>>Это уже не "однопоточном исполнителе"

I>

I>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.
Ок. Назовем многозадачно! Или MultiPromises в переводе на русский МногоОбещающие
Просто задачи по аналогии с многопоточностью вызываемые на одном ядре, вызываются в одном потоке. Сути это не меняет, так как задача может начинатья, до окончания предыдущей. Есть очередь и планировщик

Откуда гонки?

 var i=await  read();
 await write(++i);

будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
Читай и записывай хоть откуда. Тоже, что и при синхронном.

Покажи гонки если вызывается только один метод, по аналогии с однопоточным?

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

I>>

I>>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.

S> Откуда гонки?
S>

S> var i=await  read();
S> await write(++i);
S>

await это тот же колбек, только управление от эвентлупа.

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

Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

S>будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)

Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.

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

S>Читай и записывай хоть откуда. Тоже, что и при синхронном.

А тебе лишь бы теоретизировать, но не код запускать. Ты адекватный?

S> Покажи гонки если вызывается только один метод, по аналогии с однопоточным?

Все что надо, я показал, только у тебя тяга к теоретизированию

Вот смотри внимательно Вначале отрабатывают все 6 read и каждый зачитывает 0, после чего уходит в эвентлуп. Опаньки! Это уже доказывает что await работает не так как ты хотел. Далее, смотри логи в браузере

Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.

let iiii= 0;

async function read_i() {
    return iiii;
}

async function write_i(value) {
    iiii = value;
}


async function task(n, id) {
    while(n--) {
        tap('before read_i', id);
        const i = await read_i();
        tap('after read_i', id);
        await write_i(i + 1);
        tap('after write_i', id);
    }
}

function tap(msg, id) {
    console.log(msg, iiii, id);
}

debugger;

task(10, 1);
task(10, 2);
task(10, 3);
task(10, 4);
task(10, 5);
task(10, 6);

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

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

I>>>

I>>>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.

S>> Откуда гонки?
S>>

S>> var i=await  read();
S>> await write(++i);
S>>

I>await это тот же колбек, только управление от эвентлупа.

I>Следовательно, весь цикл чтение-модификация-запись неатомарны, т.к. во время await управление уходит в эвентлуп, а тот волен передать это управление куда угодно, что у него там в очереди, в т.ч. другой такой же задаче. Windows Phone в 2011-м
Это я понимаю. Но если для данного класса выполняется только один метод, то откуда гонки.

I>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

Угу был вопрос по сути про однозадачность. Там нет гонок.

S>>будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)

I>Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.
Объясни как при выполнении одной задачи могут быть гонки?

Тогда если выполняется обычный синхронный метод и один или множество асинхронный метод то будут гонки.

I>Авайт это просто колбек, получает управление от эвентлупа. А эвентлуп раздает управлении в соответствии с тем, что в него напичкано. А за эвентлуп дерутся целых несколько идентичных задач.

S>>Читай и записывай хоть откуда. Тоже, что и при синхронном.

I>

А тебе лишь бы теоретизировать, но не код запускать. Ты адекватный?

S>> Покажи гонки если вызывается только один метод, по аналогии с однопоточным?

I>Все что надо, я показал, только у тебя тяга к теоретизированию

I>Вот смотри внимательно Вначале отрабатывают все 6 read и каждый зачитывает 0, после чего уходит в эвентлуп. Опаньки! Это уже доказывает что await работает не так как ты хотел. Далее, смотри логи в браузере

I>Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.

function write_i(value) {
iiii = value;
}

I>task(10, 1);
I>task(10, 2);
I>task(10, 3);
I>task(10, 4);
I>task(10, 5);
I>task(10, 6);
write(10); тоже не будет атомарности.

await task(10, 1);
await task(10, 2);
await task(10, 3);
await task(10, 4);
await task(10, 5);
await task(10, 6);
write(10);

Никаких гонок не будет.

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

I>>Следовательно, весь цикл чтение-модификация-запись неатомарны, т.к. во время await управление уходит в эвентлуп, а тот волен передать это управление куда угодно, что у него там в очереди, в т.ч. другой такой же задаче. Windows Phone в 2011-м
S> Это я понимаю. Но если для данного класса выполняется только один метод, то откуда гонки.

Гонки когда разные ЗАДАЧИ обращаются к одному ресурсу одновременно. ЗАДАЧИ, а не только потоки. Любые задачи, любого происхождения.
И гонки надо искать в зависимости от природы многозадачности.
То есть, всего три условия
1 ресурс разделяется между задачами
2 протокол доступа неатомарный с т.з. конкретной многозадачности.
3 параллельное исполнение

I>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

S> Угу был вопрос по сути про однозадачность. Там нет гонок.

У тебя многозадачность = однопоточность. поточность это стратегия использоваться процессорного ядра, физическая реализация.
А задачи это логический уровень.

Синхронный код — одна задача на поток. Асинхронный — несколько задач на один и тот же задач, чередуются как попало.

I>>Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.
S> Объясни как при выполнении одной задачи могут быть гонки?

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

S>Тогда если выполняется обычный синхронный метод и один или множество асинхронный метод то будут гонки.

Разумеется. Асинхронный код дает гонки вне зависимости от числа потоков. Синхронный код дает гонки на нескольких потоках.

I>>Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.

[code]
S>function write_i(value) {
S> iiii = value;
S>}
S>[/cs]
S> тоже не будет атомарности.

Одного только write не хватит, т.к. read по прежнему неатомарный и весь цикл read-increment-write неатомарный.

S>

S>await task(10, 1);
S>await task(10, 2);
S>await task(10, 3);
S>await task(10, 4);
S>await task(10, 5);
S>await task(10, 6);
S>write(10);
S>

S>Никаких гонок не будет.

Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?

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

Этого можно добиться двумя путями

1. переписать полностью на синхронный код, т.е. убрать все await и async. Тогда это гарантируется синхронным однопоточным исполнителем.

2. завернуть read-increment-write в очередь, эдакий асинхронный мутекс. Соответсвенно, снова никто вклиниваться не сможет.

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

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

I>>>Следовательно, весь цикл чтение-модификация-запись неатомарны, т.к. во время await управление уходит в эвентлуп, а тот волен передать это управление куда угодно, что у него там в очереди, в т.ч. другой такой же задаче. Windows Phone в 2011-м
S>> Это я понимаю. Но если для данного класса выполняется только один метод, то откуда гонки.

I>Гонки когда разные ЗАДАЧИ обращаются к одному ресурсу одновременно. ЗАДАЧИ, а не только потоки. Любые задачи, любого происхождения.
I> И гонки надо искать в зависимости от природы многозадачности.
I>То есть, всего три условия
I>1 ресурс разделяется между задачами
I>2 протокол доступа неатомарный с т.з. конкретной многозадачности.
I>3 параллельное исполнение

Ну вот не хрена не читатель! Еще раз речь про одну!! задачи. Внутри которой все подзадачи с awaite!
I>>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

Если задачи выполняются через await никакому другому эта задача не уйдет!
Для выполнения другой задачи ты должен запустить без awaite. Но тогда проблема у тебя будет и в синхронном коде!

S>> Угу был вопрос по сути про однозадачность. Там нет гонок.

I>

У тебя многозадачность = однопоточность. поточность это стратегия использоваться процессорного ядра, физическая реализация.
I>А задачи это логический уровень.

В JS нет задач, там Обещание! В .Net задача не равно потоку. Может быть пул из одного потока, но множество задач.
Но есть планировщик со своей очередью потоков (в данном случае 1)

I>Синхронный код — одна задача на поток. Асинхронный — несколько задач на один и тот же задач, чередуются как попало.
Ну я то знаю. Уж поверь давно на asinc\awate программирую. Кстати в TS они появились раньше чем в JS

I>>>Еще раз — нет, не гарантирует и никогда не гарантировал и никогда не будет. Ты начитался ахинеи про какой то другой язык на другой платформе.
S>> Объясни как при выполнении одной задачи могут быть гонки?

I>Асинхронный однопоточный код это такая вот реализация многозадачности. Соответсвенно,несколько задач работают с одним и тем же ресурсом.
Какие несколько задач? Я говорил про одну!

S>>Тогда если выполняется обычный синхронный метод и один или множество асинхронный метод то будут гонки.

I>Разумеется. Асинхронный код дает гонки вне зависимости от числа потоков. Синхронный код дает гонки на нескольких потоках.

I>>>Результат выполнения — всегда 10. А должен быть 60. Всегда 10 потому что эвентлуп всегда загружен одинаково, потому предсказуемая работа. Когда будет недетерминизм от IO, таймера и тд, т.е. внешней системы, результат будет прыгать около нуля.

I>[code]
S>>function write_i(value) {
S>> iiii = value;
S>>}
S>>[/cs]
S>> тоже не будет атомарности.

I>Одного только write не хватит, т.к. read по прежнему неатомарный и весь цикл read-increment-write неатомарный.

S>>

S>>await task(10, 1);
S>>await task(10, 2);
S>>await task(10, 3);
S>>await task(10, 4);
S>>await task(10, 5);
S>>await task(10, 6);
S>>write(10);
S>>

S>>Никаких гонок не будет.

I>Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?
То есть у тебя при последовательном выполнении через await выполняются непоследовательно?
Тогда проблема в JS или ты где то запустил еще задачу без await

I>Атомарность будет только в том случае, когда и read и инкремент и write от начала и до конца не будут прерываться никакими другими цепочками.

I>Этого можно добиться двумя путями

I>1. переписать полностью на синхронный код, т.е. убрать все await и async. Тогда это гарантируется синхронным однопоточным исполнителем.

I>2. завернуть read-increment-write в очередь, эдакий асинхронный мутекс. Соответсвенно, снова никто вклиниваться не сможет.

Если ты будешь запускать задачи без await то покажи как это на онопотоке будет выглядеть?
Такая цепочка должна выполняться последовательно. Без гонок если конечно не запустить task без await

await task(10, 1);
await task(10, 2);
await task(10, 3);
await task(10, 4);
await task(10, 5);
await task(10, 6);
write(10);

Для параллельного выполнение на .Net ожидают через WhenAll или WhenAny
Иногда можно просто запустить долгоиграющую задачу без awaite.

А так можно использовать асинхронные очереди
https://docs.microsoft.com/ru-ru/dotnet/standard/asynchronous-programming-patterns/consuming-the-task-based-asynchronous-pattern
AsyncProducerConsumerCollection

А так JS похож на Виндовое окно с очередью сообщений

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

I>>2 протокол доступа неатомарный с т.з. конкретной многозадачности.
I>>3 параллельное исполнение

S> Ну вот не хрена не читатель! Еще раз речь про одну!! задачи. Внутри которой все подзадачи с awaite!

Ты хочешь получить гонки на одной задаче? Гонки это когда много задач

Или много под-задач.

I>>>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

S>Если задачи выполняются через await никакому другому эта задача не уйдет!

"задачи выполняются через await" — это откровенная чушь. await это синтаксический сахар над колбеками. Асинхронный код изначально нарезан на кусочки. Каждый кусочек запускается эвент-лупом. Авайт всего лишь связывает последовательность. Но это никакой не мутекс, соотвественно, в другой части кода может происходить что угодно.

S>Для выполнения другой задачи ты должен запустить без awaite. Но тогда проблема у тебя будет и в синхронном коде!

Это неверная интерпретация. Запускай хоть с авайт, хоть без него — выполняется кусочек жээс кода, который заканчивается выходом в эвент луп.
Всё. Кусочек задачи завершен. Далее эвент луп берет из очереди следующий колбек, передает управление туда. И так до скончания времен.

I>>

У тебя многозадачность = однопоточность. поточность это стратегия использоваться процессорного ядра, физическая реализация.
I>>А задачи это логический уровень.

S> В JS нет задач, там Обещание!

Еще раз — задача это логический уровень. А у тебя задача == поток. Промис это те же колбеки, только в виде паттерна. Авайт — сахар над промисами.

Очевидно, что ничего сверх колбеков авайтами не выжмешь.

I>>Синхронный код — одна задача на поток. Асинхронный — несколько задач на один и тот же задач, чередуются как попало.
S> Ну я то знаю. Уж поверь давно на asinc\awate программирую. Кстати в TS они появились раньше чем в JS

Да чтото не похоже, у тебя авайт это какой то всемогутор, который чего то там исполняет

I>>Асинхронный однопоточный код это такая вот реализация многозадачности. Соответсвенно,несколько задач работают с одним и тем же ресурсом.
S> Какие несколько задач? Я говорил про одну!

А я везде пишу — гонки возникают на более чем одной задаче. Чего ты сказать хочешь?

I>>

S>>>function write_i(value) {
S>>>    iiii = value;
S>>>}
S>>>

S>>> тоже не будет атомарности.

I>>Одного только write не хватит, т.к. read по прежнему неатомарный и весь цикл read-increment-write неатомарный.

I>>Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?
S> То есть у тебя при последовательном выполнении через await выполняются непоследовательно?

Ты запускать пробовал? Алё, это ж элементарно. Вместо этого ты мне доказываешь непойми что.

Для одной цепочки — последовательно. Для нескольких — как угодно. Авайт ничего не знает про другие цепочки, это просто связывание двух контекстов.

Я тебе страшное скажу — эвент-луп тоже не делает никакого упорядочения. Он просто выполняет в том порядке, в каком колбеки ставятся в очередь.

S>Тогда проблема в JS или ты где то запустил еще задачу без await

Теоретик, у тебя же весь код перед глазами, что мешает запустить да посмотреть?

I>>Этого можно добиться двумя путями

I>>1. переписать полностью на синхронный код, т.е. убрать все await и async. Тогда это гарантируется синхронным однопоточным исполнителем.

I>>2. завернуть read-increment-write в очередь, эдакий асинхронный мутекс. Соответсвенно, снова никто вклиниваться не сможет.

S> Если ты будешь запускать задачи без await то покажи как это на онопотоке будет выглядеть?

Нахер надо, ты примеры даже не запускаешь

Попробуй скопировать, вставить в консоль да посмотреть

S>Такая цепочка должна выполняться последовательно. Без гонок если конечно не запустить task без await

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

Собственно, я именно это и показываю

Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее

VM42:23 before read_i 0 1  << цепочка 1 начало
VM42:23 before read_i 0 2
VM42:23 before read_i 0 3
VM42:23 before read_i 0 4
VM42:23 before read_i 0 5
VM42:23 before read_i 0 6
VM42:23 after read_i 0 1   << цепочка 1 чтение закончено, 0 инкремент, и тут же идет запись
VM42:23 after read_i 1 2   << следующие 5 цепочек зачитали единицу, гы-гы-гы  
VM42:23 after read_i 1 3
VM42:23 after read_i 1 4
VM42:23 after read_i 1 5
VM42:23 after read_i 1 6
VM42:23 after write_i 1 1  << цепочка 1 запись единицы, следующие 5 цепочек ... ну, ты понял :-)

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

S> Такая цепочка должна выполняться последовательно.

Это всё, что ты мне хотел показать? Ничего, что мои все примеры показывают как await , так и его отсутствие ?

S> А так JS похож на Виндовое окно с очередью сообщений

Именно. Только ты ждешь чудес от авайт. Это просто синтаксический сахар над колбеками и ничего более.

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

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

I>>>2 протокол доступа неатомарный с т.з. конкретной многозадачности.
I>>>3 параллельное исполнение

S>> Ну вот не хрена не читатель! Еще раз речь про одну!! задачи. Внутри которой все подзадачи с awaite!

I>Ты хочешь получить гонки на одной задаче? Гонки это когда много задач

Или много под-задач.
Был вопрос про однопоточность. По сути подразумевалось про однозадачность для данного объекта.

I>>>>>Скажем, один экземпляр сделал await read и прочитал 10. Присвоения еще не было, но управление ушло в эвент луп, а в эвентлупе в очереди вызов write другого экземпляра, который пишет 8. Потом возврат в твой экземпляр, завершается await присходит присвоение 10, инкремент 10 -> 11, write и уход в эвентлуп.

S>>Если задачи выполняются через await никакому другому эта задача не уйдет!
Если ты запустил несколько задач без await, то это уже многозадачность!

I>"задачи выполняются через await" — это откровенная чушь. await это синтаксический сахар над колбеками. Асинхронный код изначально нарезан на кусочки. Каждый кусочек запускается эвент-лупом. Авайт всего лишь связывает последовательность. Но это никакой не мутекс, соотвественно, в другой части кода может происходить что угодно.

Это не сахар, а конечный автомат. Внутри стоит yield. Код разбивается на несколько методов по yield Когда вызывается await запоминается текущее состояние объекта, а после выполнения задачи вызывется Next и код выполняется дальше.
Там могут быть рекурсивные вызовы итд.

Это .Net реализация. Она же была и в TS до asinc/await в JS.

А при чем тут мьютекс? Ты же сам пишешь " Авайт всего лишь связывает последовательность", то есть части awaite выполняются последовательно.
О каких нескольких цепочках идет речь? Вторую цепочку ты можешь запустить без awaite. Тогда и синхронному коду придет кирдык!

Возьми мой код с await и посмотри. Если там будет разнобой значит дерьмо ваша JS.

Если, же ты хочешь писать многозадачный код, то неатомарный код тебе нужно синхронизировать.
Но речь то идет про однозадачность. Будь она синхронная или асинхронная.
Все твои примеры из многозадачности от которой не спасает и синхронный код.

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

I>Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее

I>

I>VM42:23 before read_i 0 1  << цепочка 1 начало
I>VM42:23 before read_i 0 2
I>VM42:23 before read_i 0 3
I>VM42:23 before read_i 0 4
I>VM42:23 before read_i 0 5
I>VM42:23 before read_i 0 6
I>VM42:23 after read_i 0 1   << цепочка 1 чтение закончено, 0 инкремент, и тут же идет запись
I>VM42:23 after read_i 1 2   << следующие 5 цепочек зачитали единицу, гы-гы-гы  
I>VM42:23 after read_i 1 3
I>VM42:23 after read_i 1 4
I>VM42:23 after read_i 1 5
I>VM42:23 after read_i 1 6
I>VM42:23 after write_i 1 1  << цепочка 1 запись единицы, следующие 5 цепочек ... ну, ты понял :-)
I>

То есть на таком коде

await task(10, 1);
await task(10, 2);
await task(10, 3);
await task(10, 4);
await task(10, 5);
await task(10, 6);
write(10);

before read_i 0 1
VM52:23 after read_i 0 1
VM52:23 after write_i 1 1
VM52:23 before read_i 1 1
VM52:23 after read_i 1 1
VM52:23 after write_i 2 1
VM52:23 before read_i 2 1
VM52:23 after read_i 2 1
VM52:23 after write_i 3 1
VM52:23 before read_i 3 1
VM52:23 after read_i 3 1
VM52:23 after write_i 4 1
VM52:23 before read_i 4 1
VM52:23 after read_i 4 1
VM52:23 after write_i 5 1
VM52:23 before read_i 5 1
VM52:23 after read_i 5 1
VM52:23 after write_i 6 1
VM52:23 before read_i 6 1
VM52:23 after read_i 6 1
VM52:23 after write_i 7 1
VM52:23 before read_i 7 1
VM52:23 after read_i 7 1
VM52:23 after write_i 8 1
VM52:23 before read_i 8 1
VM52:23 after read_i 8 1
VM52:23 after write_i 9 1
VM52:23 before read_i 9 1
VM52:23 after read_i 9 1
VM52:23 after write_i 10 1
VM52:23 before read_i 10 2
VM52:23 after read_i 10 2
VM52:23 after write_i 11 2
VM52:23 before read_i 11 2
VM52:23 after read_i 11 2
VM52:23 after write_i 12 2
VM52:23 before read_i 12 2
VM52:23 after read_i 12 2
VM52:23 after write_i 13 2
VM52:23 before read_i 13 2
VM52:23 after read_i 13 2
VM52:23 after write_i 14 2
VM52:23 before read_i 14 2
VM52:23 after read_i 14 2
VM52:23 after write_i 15 2
VM52:23 before read_i 15 2
VM52:23 after read_i 15 2
VM52:23 after write_i 16 2
VM52:23 before read_i 16 2
VM52:23 after read_i 16 2
VM52:23 after write_i 17 2
VM52:23 before read_i 17 2
VM52:23 after read_i 17 2
VM52:23 after write_i 18 2
VM52:23 before read_i 18 2
VM52:23 after read_i 18 2
VM52:23 after write_i 19 2

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

I>>Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее

I>>

I>>VM42:23 before read_i 0 1  << цепочка 1 начало
I>>VM42:23 before read_i 0 2
I>>VM42:23 before read_i 0 3
I>>VM42:23 before read_i 0 4
I>>VM42:23 before read_i 0 5
I>>VM42:23 before read_i 0 6
I>>VM42:23 after read_i 0 1   << цепочка 1 чтение закончено, 0 инкремент, и тут же идет запись
I>>VM42:23 after read_i 1 2   << следующие 5 цепочек зачитали единицу, гы-гы-гы  
I>>VM42:23 after read_i 1 3
I>>VM42:23 after read_i 1 4
I>>VM42:23 after read_i 1 5
I>>VM42:23 after read_i 1 6
I>>VM42:23 after write_i 1 1  << цепочка 1 запись единицы, следующие 5 цепочек ... ну, ты понял :-)
I>>

S>То есть на таком коде
S>

S>await task(10, 1);
S>await task(10, 2);
S>await task(10, 3);
S>await task(10, 4);
S>await task(10, 5);
S>await task(10, 6);
S>write(10);
S>

Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?

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

I>>Ты хочешь получить гонки на одной задаче? Гонки это когда много задач

Или много под-задач.
S> Был вопрос про однопоточность. По сути подразумевалось про однозадачность для данного объекта.

Ты путаешь однопоточность и однозадачность.

S>>>Если задачи выполняются через await никакому другому эта задача не уйдет!
S>Если ты запустил несколько задач без await, то это уже многозадачность!

Капитан, я про это и пишу!

S> Это не сахар, а конечный автомат. Внутри стоит yield.

Стоит или не стоит, это прячется компилятором. Один из вариантов это трансляция в промисы, второй вариант — нативный await, еще вариант — yield, еще вариант — конечный вариант, самый упоротый из всех.
И, о ужас, еще вариант — обычные колбеки.

Функционально все это сводится к колбекам. Никаких преимуществ сверх этого нет и не будет.

S> А при чем тут мьютекс? Ты же сам пишешь " Авайт всего лишь связывает последовательность", то есть части awaite выполняются последовательно.

А потому, что я изначально пишу про многозадачность, а именно — асинхронный однопоточный код.

S>О каких нескольких цепочках идет речь? Вторую цепочку ты можешь запустить без awaite. Тогда и синхронному коду придет кирдык!

Я именно про это и пишу.

S>Возьми мой код с await и посмотри. Если там будет разнобой значит дерьмо ваша JS.

Ты похоже влез и начал не читая махать шашкой.

Читай себя

будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
Читай и записывай хоть откуда. Тоже, что и при синхронном.

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

S>Если, же ты хочешь писать многозадачный код, то неатомарный код тебе нужно синхронизировать.

И про это я тоже пишу. Все мои примерно про многозадачность в жээсе и про необходимость синхронизации.

S>Но речь то идет про однозадачность. Будь она синхронная или асинхронная.

S>Все твои примеры из многозадачности от которой не спасает и синхронный код.

Бинго! С этого все и начиналось. Только надо было читать внимательно.

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

I>Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?
Был вопрос приведи пример где будет i++ не атомарным в однопотоке
Ты начал приводить примеры с async и добавил, что JS выполняется в одном потоке.
Тогда я сказал ок. Какие могут быть проблемы в однозадачном режиме с await?
Потому, что если будет запуск без await то и синхронный код с гонками.
Только и всего. Наконец ты понял

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

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

I>>>Ты хочешь получить гонки на одной задаче? Гонки это когда много задач

Или много под-задач.
S>> Был вопрос про однопоточность. По сути подразумевалось про однозадачность для данного объекта.

I>Ты путаешь однопоточность и однозадачность.
Я тебе про однозадачность уже много расписывал. Ничего я не путаю.

S>>>>Если задачи выполняются через await никакому другому эта задача не уйдет!
S>>Если ты запустил несколько задач без await, то это уже многозадачность!

I>Капитан, я про это и пишу!
А я тебе пишу про однозадачность!

S>> Это не сахар, а конечный автомат. Внутри стоит yield.

I>Стоит или не стоит, это прячется компилятором. Один из вариантов это трансляция в промисы, второй вариант — нативный await, еще вариант — yield, еще вариант — конечный вариант, самый упоротый из всех.
I>И, о ужас, еще вариант — обычные колбеки.

I>Функционально все это сводится к колбекам. Никаких преимуществ сверх этого нет и не будет.

S>> А при чем тут мьютекс? Ты же сам пишешь " Авайт всего лишь связывает последовательность", то есть части awaite выполняются последовательно.

I>А потому, что я изначально пишу про многозадачность, а именно — асинхронный однопоточный код.
Потому, что ты не читатель! Я тебе сразу написал про однозадачность.

S>>О каких нескольких цепочках идет речь? Вторую цепочку ты можешь запустить без awaite. Тогда и синхронному коду придет кирдык!

I>Я именно про это и пишу.

S>>Возьми мой код с await и посмотри. Если там будет разнобой значит дерьмо ваша JS.

I>Ты похоже влез и начал не читая махать шашкой.

I>Читай себя
I>

I>будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
I>Читай и записывай хоть откуда. Тоже, что и при синхронном.

I>Собственно, здесь ты наврал. Во первых, исполнение жээс это один поток, а во вторых, читать и записывать хоть откуда не выйдет и я показал, почему именно не выйдет.

S>>Если, же ты хочешь писать многозадачный код, то неатомарный код тебе нужно синхронизировать.

I>И про это я тоже пишу. Все мои примерно про многозадачность в жээсе и про необходимость синхронизации.

S>>Но речь то идет про однозадачность. Будь она синхронная или асинхронная.

I>

S>>Все твои примеры из многозадачности от которой не спасает и синхронный код.

I>Бинго! С этого все и начиналось. Только надо было читать внимательно.
Во во. Я тебе сразу писал про однозадачность
B i++ будет атомарным при любом режиме.
В .Net используют для SpinLock вернее Interlocked.Increment(ref nextTaskIndex)

Ладно. Зря потратил время. Извини. Завелся. Только вот за что минусы я так и не понял
Ну промисы это не всегда калбеки
Метод Promise.resolve(value) возвращает Promise выполненый с переданным значением.

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

I>>Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?
S>Был вопрос приведи пример где будет i++ не атомарным в однопотоке

Але — тут вся подветка про многозадачность. Товарищ на полном серьез утверждал, что

await серилизует доступ к ресурсу

Тебе понятно, про что речь шла?

S>Ты начал приводить примеры с async и добавил, что JS выполняется в одном потоке.

См выше.

S>Тогда я сказал ок. Какие могут быть проблемы в однозадачном режиме с await?

Стоит таки читать, особенно когда влазишь в конец беседы.

S>Потому, что если будет запуск без await то и синхронный код с гонками.
S> Только и всего. Наконец ты понял

Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.

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

I>>Ты путаешь однопоточность и однозадачность.
S> Я тебе про однозадачность уже много расписывал. Ничего я не путаю.

Тут разговор длится две недели, а ты влез и начал шашкой махать.

I>>Капитан, я про это и пишу!
S> А я тебе пишу про однозадачность!
I>>А потому, что я изначально пишу про многозадачность, а именно — асинхронный однопоточный код.
S>Потому, что ты не читатель! Я тебе сразу написал про однозадачность.

То есть, ты влез в беседу про многозадачный код и попросил показать гонки в однозадачном коде? Ты адекватен?

S> Ладно. Зря потратил время. Извини. Завелся. Только вот за что минусы я так и не понял

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

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

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

I>>>Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?
S>>Был вопрос приведи пример где будет i++ не атомарным в однопотоке

I>Але — тут вся подветка про многозадачность. Товарищ на полном серьез утверждал, что
I>

I>await серилизует доступ к ресурсу

I>Тебе понятно, про что речь шла?
Я не читал всю ветку. Я про многопоточность, потом привел пример про однозадачность.
Я не виноват, что ты меня не читаешь еще и минусы ставишь.

S>>Ты начал приводить примеры с async и добавил, что JS выполняется в одном потоке.

I>См выше.

S>>Тогда я сказал ок. Какие могут быть проблемы в однозадачном режиме с await?

I>Стоит таки читать, особенно когда влазишь в конец беседы.
Угу то есть я и виноват, что ты меня не читаешь.
S>>Потому, что если будет запуск без await то и синхронный код с гонками.
S>> Только и всего. Наконец ты понял

I>Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.
Я не читал всю ветку у меня был вопрос только по одному вопросу. Все.
То есть стоит читать сообщения других. Только и всего. Я же на русском пишу

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

I>>Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.
S> Я не читал всю ветку у меня был вопрос только по одному вопросу. Все.
S> То есть стоит читать сообщения других. Только и всего. Я же на русском пишу

Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?

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

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

I>>>Похоже, что это ты понял, про что речь была за две недели до твоего пришествия.
S>> Я не читал всю ветку у меня был вопрос только по одному вопросу. Все.
S>> То есть стоит читать сообщения других. Только и всего. Я же на русском пишу

I>Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?
Все давай закончим. Я пишу тебе про одно, ты мне отвечаешь про другое. Я тебе говорю, что ты нифига не читатель, но ты продолжаешь дальше.
Я тебе пишу
S>
S>await task(10, 1);
S>await task(10, 2);
S>await task(10, 3);
S>await task(10, 4);
S>await task(10, 5);
S>await task(10, 6);
S>write(10);
S>

S>Никаких гонок не будет.

ответ

Снова теоретизирование. Ты запускать пробовал? Почему результат по прежнему 10 когда должен быть 60?

Прошло еще куча ответов
и вдруг наконец

Зачем ты добавляешь авейт? Чего ты хочешь мне сказать?

Охренеть, а я тут распинаюсь, ссылочки ищу итд.
Потратил кучу времени. Нахрен этот RSDN сдался

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

I>>Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?
S> Все давай закончим. Я пишу тебе про одно, ты мне отвечаешь про другое. Я тебе говорю, что ты нифига не читатель, но ты продолжаешь дальше.
S>Я тебе пишу
S>>
S>>await task(10, 1);
S>>await task(10, 2);
S>>await task(10, 3);
S>>await task(10, 4);
S>>await task(10, 5);
S>>await task(10, 6);
S>>write(10);

Я дал тебе цельный пример кода, а ты зачем то сделал await впереди task

Я на это обратил внимание не сразу.

Речь то была не про превращение параллельного когда в последовательный, а про серилизацию доступа к ресурсу.

S>Охренеть, а я тут распинаюсь, ссылочки ищу итд.
S>Потратил кучу времени. Нахрен этот RSDN сдался

Ога, рсдн виноват да.

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

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

I>>>Ога. Ты перечитай мои первые ответы тебе. Ты что, хочешь что бы я с первых строчек задетектил что ты чего то там не прочитал?
S>> Все давай закончим. Я пишу тебе про одно, ты мне отвечаешь про другое. Я тебе говорю, что ты нифига не читатель, но ты продолжаешь дальше.
S>>Я тебе пишу
S>>>
S>>>await task(10, 1);
S>>>await task(10, 2);
S>>>await task(10, 3);
S>>>await task(10, 4);
S>>>await task(10, 5);
S>>>await task(10, 6);
S>>>write(10);

I>Я дал тебе цельный пример кода, а ты зачем то сделал await впереди task

I>Я на это обратил внимание не сразу.

I>Речь то была не про превращение параллельного когда в последовательный, а про серилизацию доступа к ресурсу.
Вообще то все началось вот отсуда
I>>>Ты можешь заменить операции с файлом, скажем на такие

I>>>
I>>>async read(): number { return i }

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

S>>Это уже не "однопоточном исполнителе"

I>
I>Это обычный джаваскрипт, его исполнение однопоточно. Но это асинхронный код, хотя здесь и нет никакого IO. Соответственно, гонки — в полный рост и именно там, откуда и стоит ждать.
Откуда гонки?

 var i=await  read();
 await write(++i);

будут вызываться только в одном методе (await гарантирует последовательность вызовов из разных потоков)
Читай и записывай хоть откуда. Тоже, что и при синхронном.

Покажи гонки если вызывается только один метод, по аналогии с однопоточным?

Ладно трачу время и нервы! нахрен. Я еще и виноват оказался.

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	28.06.20 18:36
Оценка:	-1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	28.06.20 19:24
Оценка:	1 (1) -1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	28.06.20 20:47
Оценка:	-1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	29.06.20 09:01
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	29.06.20 10:12
Оценка:	-1