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

I>"Недетерминированный порядок исполнения двух задач"
I>Если непонятно — можешь рассматривать код выше как небольшой фрагмент применения зеленых потоков. Разницы абсолютно никакой. Все проблемы абсолютно одинаковы.

Опять двадцать пять.

V>>Например, даже любимый твой Майкрософт в доках пишет, что кооперативная многозадачность позволяется избегать лишних гонок и лишних же блокировок. Но у тебя как был затык в понимании "гонок", так и не рассосался до сих пор. И ведь не страшно же тебе на весь интернет так подставляться, не? )) С работы не уволят, случаем? ))

I>Микрософт говорит совсем про другое. См пример выше. Этот код задачи, таких в джаваскрипте можно запустить хоть тысячу за раз. Все они будут работать в одном потоке по правилам кооперативной многозадачности. Собтсвенно, ровно ничем не отличается от зеленых потоков.
I>Отсюда получаем тот самый "недетерминированый порядок"

Я вот уже близок, чтобы повторить тебе всё то, что было в той эпической дискуссии, на которую ты, на свою беду, постоянно ссылаешься. ))


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

Тем не менее, нам нужна лишь изоляция от конкурирующего доступа, т.е. изоляция от тех самых гонок. Если гонок нет, то "изоляция" соблюдается или нет?


I>Это не разрезание, а связывание. Задача состоит из кусков, которые, возможно, выполняются в разных потоках, или, например, задача прибита к эвентлупу.

Это лишь точка зрения на происходящее.
Понимаешь, в вытесняющей многозадачности АБСОЛЮТНО так же. Потому что все юзверские потоки — это логические потоки. Физические потоки — это процессоры/ядра/потоки_в_многопоточных_ядрах.

ОС может вытеснить твой логический поток, затем продолжить его выполнение из ДРУГОГО физического потока, так? Но при этом, хотя логический поток переползет на другой физический поток, ОС предоставляет нам гарантии, что никакой участок кода логического потока не будет будет выполнен одновременно. Чтобы одновременно выполнять некий участок кода, нам надо будет явным образом создать еще один логический поток уровня ОС. ))

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

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

Ну вот включи воображение, представь, что у тебя есть два пользовательских потока (назовём их корутины), которые обслуживаются только одним потоком ОС. Эти две корутины делят м/у собой некую очередь, одна корутина что-то кладет в очередь и вызывает yield, вторая корутина забирает что-то из очереди и, когда очередь пуста, тоже вызывает yield. Нужно ли нам для этого сценария защищать такую очередь с помощью критической секции или нет?

(сорри, но если опять не осилишь... ну ты понял)


V>>И все это с единственной целью — уйти от вытесняющей ядерной многозадачности в сторону кооперативной юзверской.
I>У тебя должен быть хороший ответ — как 1000 зеленых потоков смогут корректно работать с глобальным состоянием.

Зачем это мне? Это нужно твоему жабаскрипту, а так же Lisp, Scheme и вообще всем тем языкам, которые оперируют "контекстом".
Т.е., в твоём жабаскрипте на любой вызов любой ф-ии или лямбды всегда неявно протаскивается некий "контекст". Эти контексты связаны друг с другом по цепочке вызовов и образуют т.н. связанную "область видимости" глобальных переменных и ф-ий (которые в жабаскрипте и в лиспе — тоже лишь "переменные", хранящие указатель на тело ф-ии). Т.е. фиг с ними, с переменными, но, блин, когда ф-ия представлена переменной — тот тут надо быть оч осторожным, не? ))

Собсно, чем мне не нравится жабасрипт — это тем, что без навыков отслеживать цепочку хотя бы из 3-х контекстов ты эффективно программировать не будешь. Именно поэтому жабаскрипт пестрит вот таким высмеянным сто раз синтаксисом:

    })
   })
  })
 })

Что это всё попытка "обрезать" зависимости от вышестоящего контекста.
И именно поэтому в жабаскрипте принято такое правило хорошего тона, что код библиотек, по возможности, вообще не определяет никаких глобальных ф-ий, все ф-ии (т.е. указатели на безымянные ф-ии) принято складывать в некий объект, который служит как АПИ библиотеки.

В С++ с этим проще, контекстом можно управлять явно (вызов метода объекта) или не использовать вовсе. Запросто можно отказаться от глобальных переменных, потому что глобальные ф-ии — это именно ф-ии, а не переменные, хранящие адрес ф-ии с возможностью этот адрес перезаписать.

Конечно, в многопоточных С++ программах глобальный контекст или не используют вовсе, или он представлен такими объектами, которые безопасны для конкурентного доступа из разных потоков. Это азы многопоточного программирования, собсно.

И конечно, многократно порицаемый оператор const позволяет сделать так, чтобы некий глобальный объект, безопасный для многопоточного использования, нельзя было перезаписать (как минимум без помощи хаков), потому что сама операция перезаписи разделяемой переменной не является потокобезопасной.

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

I>"Недетерминированный порядок исполнения двух задач"
I>Если непонятно — можешь рассматривать код выше как небольшой фрагмент применения зеленых потоков. Разницы абсолютно никакой. Все проблемы абсолютно одинаковы.

Опять двадцать пять.

V>>Например, даже любимый твой Майкрософт в доках пишет, что кооперативная многозадачность позволяется избегать лишних гонок и лишних же блокировок. Но у тебя как был затык в понимании "гонок", так и не рассосался до сих пор. И ведь не страшно же тебе на весь интернет так подставляться, не? )) С работы не уволят, случаем? ))

I>Микрософт говорит совсем про другое. См пример выше. Этот код задачи, таких в джаваскрипте можно запустить хоть тысячу за раз. Все они будут работать в одном потоке по правилам кооперативной многозадачности. Собтсвенно, ровно ничем не отличается от зеленых потоков.
I>Отсюда получаем тот самый "недетерминированый порядок"

Я вот уже близок, чтобы повторить тебе всё то, что было в той эпической дискуссии, на которую ты, на свою беду, постоянно ссылаешься. ))


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

Тем не менее, нам нужна лишь изоляция от конкурирующего доступа, т.е. изоляция от тех самых гонок. Если гонок нет, то "изоляция" соблюдается или нет?


I>Это не разрезание, а связывание. Задача состоит из кусков, которые, возможно, выполняются в разных потоках, или, например, задача прибита к эвентлупу.

Это лишь точка зрения на происходящее.
Понимаешь, в вытесняющей многозадачности АБСОЛЮТНО так же. Потому что все юзверские потоки — это логические потоки. Физические потоки — это процессоры/ядра/потоки_в_многопоточных_ядрах.

ОС может вытеснить твой логический поток, затем продолжить его выполнение из ДРУГОГО физического потока, так? Но при этом, хотя логический поток переползет на другой физический поток, ОС предоставляет нам гарантии, что никакой участок кода логического потока не будет будет выполнен одновременно. Чтобы одновременно выполнять некий участок кода, нам надо будет явным образом создать еще один логический поток уровня ОС. ))

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

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

Ну вот включи воображение, представь, что у тебя есть два пользовательских потока (назовём их корутины), которые обслуживаются только одним потоком ОС. Эти две корутины делят м/у собой некую очередь, одна корутина что-то кладет в очередь и вызывает yield, вторая корутина забирает что-то из очереди и, когда очередь пуста, тоже вызывает yield. Нужно ли нам для этого сценария защищать такую очередь с помощью критической секции или нет?

(сорри, но если опять не осилишь... ну ты понял)


V>>И все это с единственной целью — уйти от вытесняющей ядерной многозадачности в сторону кооперативной юзверской.
I>У тебя должен быть хороший ответ — как 1000 зеленых потоков смогут корректно работать с глобальным состоянием.

Зачем это мне? Это нужно твоему жабаскрипту, а так же Lisp, Scheme и вообще всем тем языкам, которые оперируют "контекстом".
Т.е., в твоём жабаскрипте на любой вызов любой ф-ии или лямбды всегда неявно протаскивается некий "контекст". Эти контексты связаны друг с другом по цепочке вызовов и образуют т.н. связанную "область видимости" глобальных переменных и ф-ий (которые в жабаскрипте и в лиспе — тоже лишь "переменные", хранящие указатель на тело ф-ии). Т.е. фиг с ними, с переменными, но, блин, когда ф-ия представлена переменной — тот тут надо быть оч осторожным, не? ))

Собсно, чем мне не нравится жабасрипт — это тем, что без навыков отслеживать цепочку хотя бы из 3-х контекстов ты эффективно программировать не будешь. Именно поэтому жабаскрипт пестрит вот таким высмеянным сто раз синтаксисом:

    })
   })
  })
 })

Что это всё попытка "обрезать" зависимости от вышестоящего контекста.
И именно поэтому в жабаскрипте принято такое правило хорошего тона, что код библиотек, по возможности, вообще не определяет никаких глобальных ф-ий, все ф-ии (т.е. указатели на безымянные ф-ии) принято складывать в некий объект, который служит как АПИ библиотеки.

Потому что когда скрипт выполняет код, даже просто ОБЪЯВЛЯЮЩИЙ некую глобальную ф-ию, то он выделяет в том самом контексте-словаре ячейку для её хранения. Ну конечно, если несколько потоков будут оперировать одним и тем же контекстом, как же все они, несчастные, будут выделять одну и ту же ячейку для хранения адреса только что пережёванной интерпретатором ф-ии? ))

В С++ с этим проще, контекстом можно управлять явно (вызов метода объекта) или не использовать вовсе. Запросто можно отказаться от глобальных переменных, потому что глобальные ф-ии — это именно ф-ии, а не переменные, хранящие адрес ф-ии с возможностью этот адрес перезаписать.

Конечно, в многопоточных С++ программах глобальный контекст или не используют вовсе, или он представлен такими объектами, которые безопасны для конкурентного доступа из разных потоков. Это азы многопоточного программирования, собсно.

И конечно, многократно порицаемый оператор const позволяет сделать так, чтобы некий глобальный объект, безопасный для многопоточного использования, нельзя было перезаписать (как минимум без помощи хаков), потому что сама операция перезаписи разделяемой переменной не является потокобезопасной.