Сообщение Re[31]: Для тех, кто смеется над JavaScript от 29.06.2020 11:02
Изменено 29.06.2020 11:08 Pauel
Re[31]: Для тех, кто смеется над JavaScript
Здравствуйте, 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>>> тоже не будет атомарности.
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
Одна цепочка будет выполняться последовательно. Но выполнение будет прерываться и уходить эвент луп. После этого эветлуп передает управление не этой же цепочке, а той, что запланировала колбек ранее, после чего вернется и продолжит. При этом разделяемый ресурс может находиться уже в неизвестном состоянии, т.к. мы не знаем, что что еще эвентлуп успел поназапускать.
Собственно, я именно это и показываю
Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее
Понятно что происходит?
S> А так JS похож на Виндовое окно с очередью сообщений
Именно. Только ты ждешь чудес от авайт. Это просто синтаксический сахар над колбеками и ничего более.
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 чтение закончено
VM42:23 after read_i 1 2
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 записьПонятно что происходит?
S> А так JS похож на Виндовое окно с очередью сообщений
Именно. Только ты ждешь чудес от авайт. Это просто синтаксический сахар над колбеками и ничего более.
Re[31]: Для тех, кто смеется над JavaScript
Здравствуйте, 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>>> тоже не будет атомарности.
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
Одна цепочка будет выполняться последовательно. Но выполнение будет прерываться и уходить эвент луп. После этого эветлуп передает управление не этой же цепочке, а той, что запланировала колбек ранее, после чего вернется и продолжит. При этом разделяемый ресурс может находиться уже в неизвестном состоянии, т.к. мы не знаем, что что еще эвентлуп успел поназапускать.
Собственно, я именно это и показываю
Берешь мой пример, вставляешь в консоль, жмешь энтер и видишь следующее
Понятно что происходит? Авайт выстраивает последовательность только одного экземпляра цепочки, про другие он ничего не знает. А поскольку все это делается через эвент-луп, то другие цепочки вклиниваются перезатирают результаты друг друга.
S> А так JS похож на Виндовое окно с очередью сообщений
Именно. Только ты ждешь чудес от авайт. Это просто синтаксический сахар над колбеками и ничего более.
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> А так JS похож на Виндовое окно с очередью сообщений
Именно. Только ты ждешь чудес от авайт. Это просто синтаксический сахар над колбеками и ничего более.