Здравствуйте, Ночной Смотрящий, Вы писали:

I>>, которая возникает из за IOCP и BeginRead, аккурат кооперативная многозадачность и есть.

НС>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.

Не могут они без этого справляться. Таски унутре continuation-based, то есть, практически кооперативная многозадачность.

I>>Мой вариант задачи и её решения есть в этом форуме, а твоего нет и скорее всего никогда не будет. Так шта...

НС>Ссылки давай, я за тобой не слежу что и где ты писал.

Можно даже проще

var i = 0;

function read() { return i; }

function write(v) { i = v; }


write(++read()); // ничего военного, простой синхронный код

Теперь представь,

1 что i это разделяемый ресурс, а read и write сделаны в духе APM, т.е. Begin-End
2 есть N читателей и писателей и все жаждут сделать одновременно
3 все это разумеется в одном физическом потоке.

скажем, если сделать это в лоб, и таких операций будет 100, то в синхронном варианте результат будет 100, а в асинхронном это будет какое то число, в зависимости от того, какие задержки между begin-end-read-write.

Вот эту проблему нужно решать всегда, когда ты пишешь в APM стиле чтото более сложное чем hello world. Более того, в тасках она растёт в полный рост и решать её нужно руками, но попроще чем в APM. В Зеленых потоках её тоже надо решать, при чем еще проще, чем в тасках.

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


S>>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?
I>Если в одном потоке всякие IOCP, BeginXXX, EndXXX, то асинхронщина здесь и есть та самая кооперативная многозадачность.
Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают. Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.

Это всё упрощённо и очень схематично конечно, реализации могут быть разные. Но варианта "асинхронщина здесь и есть та самая кооперативная многозадачность" точно не будет. За бесполезностью


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

Микрософт всунула в таски все что только смогла придумать
разработчики в МС сами не понимают, как работают таски
когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски

I>Связь вполне простая — всунули столько, что сами не смогли это осмыслить, пример — вижла.
Эмм... а мсье смотрел отладчиком, где и как используются таски в VS? А то за уверенность — 5, за знания — 0 получается Если коротко, таски в VS на сегодня не используются практически нигде, там где используются — совмещены с await и не блокируют UI-поток студии.


S>>Какому из твоих утверждений верить?
I>Таски это плохая реализация зеленых потоков. Все смешали в кучу — и асинхронщину, и контексты и потоки, все до чего смогли дотянуться.
Мы по кругу ходим. Таски — это _не_ зелёные потоки. Это реализация вообще другой модели, эдакая смесь futures + continuation-passing.


S>>В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"
I>Там много больше, чем одна модель. Из того, что все все перечисленное по отдельности нужно, вовсе не значит, что мешанина из всего этого и есть то самое наилучшее решение.
Блин, этот спор мне чем-то напоминает "linq зло, т.к. в словарях и базах данных операции почти не перекрываются": такой же сфероконизм без аргументации. Если коротко — таски покрывают типовые задачи почти для всей асинхронщины так же, как linq — операции по фильтрации/проекции данных.

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


I>>>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
S>>Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.

I>Я await сам написал, когда этого в языке еще не было. Так шта..
Сорри, но не катит. "Использовал A" и "Разработал B и назвал его A" — не одно и то же. Возвращаюсь к вопросу: так какой там "гарантированный АДЪ" с отладкой тасков?

I>Итого — кода у тебя нет. До свидания.
Троллинг тоже не катит. "Поскипал код в ответе" и "кода у тебя нет" — тоже разные вещи.

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

НС>>In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.

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

Определение не идеальное, но вполне понятное. "Native OS capabilities" имеются в виду не вообще, а именно на поддержку нескольких нитей.
Например, одна из классических реализаций — libc_r во FreeBSD — работала так:

все системные вызовы, которые могут блокироваться, заменяются на врапперы, которые переводят соответствующую активность на ожидание в select()

по таймерному сигналу планировщик может переключить нить, системно- и платформенно-зависимыми средствами сохранив и восстановив полный контекст (регистры процессора)

опять же системно-зависимыми средствами строятся стеки нитей (через mmap() с MAP_STACK)

Реализация была не идеальная — некоторые блокировки не ловились, не было вкусняшек типа per-thread page fault, где-то вместо select() приходилось поллить, non-blocking на fd мог мешать соседям... но несмотря на это получалась вполне себе многонитевая обстановка без явной поддержки в программе.

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

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

S>Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают. Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.

Это просто конкретная реализация. node.js построен унутре на IOCP модели, и нет никакого "продолжает выполнение в потоке из IOCP-пула", там всего один поток, другого в принципе быть не может.

S>Это всё упрощённо и очень схематично конечно, реализации могут быть разные. Но варианта "асинхронщина здесь и есть та самая кооперативная многозадачность" точно не будет. За бесполезностью

Ога, после твоих слов node.js перестал существовать, да еще и задним числом.

I>>Связь вполне простая — всунули столько, что сами не смогли это осмыслить, пример — вижла.
S>Эмм... а мсье смотрел отладчиком, где и как используются таски в VS? А то за уверенность — 5, за знания — 0 получается Если коротко, таски в VS на сегодня не используются практически нигде, там где используются — совмещены с await и не блокируют UI-поток студии.

Ты определись, используются или нет. Не важно, где и с чем совмещены. Кроме того, я не говорил, что они блокирую UI, я говорил что вижла висит. UI, буквально, живой, но от него толку нет.
Вобщем, прекращай за меня додумывать.

I>>Таски это плохая реализация зеленых потоков. Все смешали в кучу — и асинхронщину, и контексты и потоки, все до чего смогли дотянуться.
S>Мы по кругу ходим. Таски — это _не_ зелёные потоки. Это реализация вообще другой модели, эдакая смесь futures + continuation-passing.

А что по твоему унутре зеленых потоков, чудеса и магия ? Там все те же самые continuation, отсюда возможность переключать выполнение ниток руками. При желании колбеки можно упаковать во что угодно, хоть в futures, хоть в stackless короутины. См пейтон.

I>>Там много больше, чем одна модель. Из того, что все все перечисленное по отдельности нужно, вовсе не значит, что мешанина из всего этого и есть то самое наилучшее решение.
S>Блин, этот спор мне чем-то напоминает "linq зло, т.к. в словарях и базах данных операции почти не перекрываются": такой же сфероконизм без аргументации. Если коротко — таски покрывают типовые задачи почти для всей асинхронщины так же, как linq — операции по фильтрации/проекции данных.

Таски при необходимости одной лишь асинхронщины это какая то катастрофа. Более громоздкого решения сложно даже придумать.

S>И да, таски не отменяют прочих API, не запрещают специфичных расширений и не всегда идеально смешиваются. Точно так же, как linq. Что, выбрасываем?

Таски это прежде всего переусложненный всеобъемлющий всемогутор. Их имеет смысл использовать только когда нужно всё и сразу. Хуже всего, что язык прибили гвоздями к либе.

Если бы в С# был экспрешном и работал как yield в Питоне, для той же асинхронщины можно сделать более простое и эффективное решение, где не надо ломать часами голову, исправляя чей то дедлок.

I>>Я await сам написал, когда этого в языке еще не было. Так шта..
S>Сорри, но не катит. "Использовал A" и "Разработал B и назвал его A" — не одно и то же. Возвращаюсь к вопросу: так какой там "гарантированный АДЪ" с отладкой тасков?

Реши задачу, поговорим.

I>>Итого — кода у тебя нет. До свидания.
S>Троллинг тоже не катит. "Поскипал код в ответе" и "кода у тебя нет" — тоже разные вещи.

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

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


S>>Нет. Хотя бы потому, что IOCP и "в одном потоке" не соотносятся вообще никак, почитай как оно работают. Запрос инициируется с рабочего потока, запихивается в очередь iocp, по завершению — продолжает выполнение в потоке из IOCP-пула. Кооперативной многозадачности тут нет: обработчики iocp будут выполняться параллельно вплоть до исчерпания пула потоков.
I>Это просто конкретная реализация. node.js построен унутре на IOCP модели, и нет никакого "продолжает выполнение в потоке из IOCP-пула", там всего один поток, другого в принципе быть не может.
Эхх...
1. Вообще-то Node.js не однопоточен, он только притворяется. Это к слову о "ExecutionContext не нужен", если что
2. Называть недостаток js преимуществом... ну, не знаю


I>Кроме того, я не говорил, что они блокирую UI, я говорил что вижла висит. UI, буквально, живой, но от него толку нет.
?

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

Но ок, спорить не буду за очевидной бессмысленностью — придётся сначала выяснять, с чего ты решил что проблема вообще в тасках, а затем мы съедем ещё на какую-нибудь тему. Нафиг-нафиг

I>>>Таски это плохая реализация зеленых потоков.
S>>Мы по кругу ходим. Таски — это _не_ зелёные потоки. Это реализация вообще другой модели, эдакая смесь futures + continuation-passing.
I>А что по твоему унутре зеленых потоков, чудеса и магия ? Там все те же самые continuation, отсюда возможность переключать выполнение ниток руками. При желании колбеки можно упаковать во что угодно, хоть в futures, хоть в stackless короутины. См пейтон.
1. Велосипед содержит резину и шестерёнки.
2. Камаз содержит резину и шестерёнки.
3. Будем доказывать тождество?


S>>Блин, этот спор мне чем-то напоминает "linq зло, т.к. в словарях и базах данных операции почти не перекрываются": такой же сфероконизм без аргументации. Если коротко — таски покрывают типовые задачи почти для всей асинхронщины так же, как linq — операции по фильтрации/проекции данных.
I>Таски при необходимости одной лишь асинхронщины это какая то катастрофа. Более громоздкого решения сложно даже придумать.
Снова повторю вопрос — ты использовал код с await на практике? Куда уж проще-то?

S>>И да, таски не отменяют прочих API, не запрещают специфичных расширений и не всегда идеально смешиваются. Точно так же, как linq. Что, выбрасываем?
I>Таски это прежде всего переусложненный всеобъемлющий всемогутор. Их имеет смысл использовать только когда нужно всё и сразу.
Ок, что у нас из основного интерфейса в тасках — Start/Wait/Continuation/Cancellation — не используется практически в любом из вариантов? Остальная магия, включая шедулеры, нужна в первую очередь для инфраструктурщиков и большинством разработчиков напрямую не используется никогда.

I>Хуже всего, что язык прибили гвоздями к либе.
Не более, чем foreach к IEnumerable<>. Обычный биндинг по паттерну, попробуй найти task вот тут

Автор: Sinix
Дата: 25.04.14

I>Если бы в С# был экспрешном и работал как yield в Питоне, для той же асинхронщины можно сделать более простое и эффективное решение, где не надо ломать часами голову, исправляя чей то дедлок.
В сотый раз — за await/task может быть любая реализация, дедлоки детектятся из коробки, см первый рисунок тут. Изучите наконец тему, по которой спорите!


I>>>Итого — кода у тебя нет. До свидания.
S>>Троллинг тоже не катит. "Поскипал код в ответе" и "кода у тебя нет" — тоже разные вещи.
I>Это не троллинг, это факт. Реши задачу и я покажу тебе все что ты хочешь прямо в твоем коде.

Да ладно, т.е. самому дописать до

        static async Task<int> Sample()
        { 
            Func<int, int> future = i => i*10;

            var items = Enumerable.Range(0, 10);

            var tasks = items.Select(i => Task.Factory.FromAsync<int, int>(
                future.BeginInvoke, future.EndInvoke,
                i, null));

            await Task.WhenAll(tasks);

            return tasks.Sum(t => t.Result);
        }

        static void Main(string[] args)
        {
            Console.WriteLine(Sample().Result);
            Console.ReadKey();
        }

лень?

Всё как просил —

А вот извраты FileStream.BeginRead в своём уме никто не использует
В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

Где там АДЪ?

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

Я скипнул пока что

S>Да ладно, т.е. самому дописать до
S>

S>

S>лень?

От тебя требовалось сделать разделяемый ресурс и ты с этим не справился.

1 некоторая переменная, котороую читают и пишут писатели-читатели
2 доступ к ней делается через begin-end

У тебя вообще нет разделяемого ресурса и ты сделал совсем не то АПИ про которое мы говорили.

Можешь поискать в данном форуме решение от vdimas, если очень хочется, все что я обещал показать тебе, я показал ему.

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


I>От тебя требовалось сделать разделяемый ресурс и ты с этим не справился.
Сорри, но я завязываю.

Попробуй перечитать свою постановку задачи. Чтоб далеко не лазил — вот цитата:

А вот извраты FileStream.BeginRead в своём уме никто не использует
В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

и найди там слова "разделяемый ресурс".

Тем не менее, если так хочется ресурс<>последовательность, рекомендую посмотреть в сторону rx. .FromAsync() там тоже есть, остальное элементарно.

Закругляюсь, спасибо, было приятно поспорить.

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

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

Они не просто могут, они справляются.

I> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.

Нет. Continuation там для описания зависимостей, а не для многозадачности. Многозадачность там обычная, вытесняющая.
Ты ваот что путаешь, похоже: зеленые потоки могут использоваться в качестве варианта реализации continuation monad практически в лоб. Таски же реализуют СМ по другому. Ты же думаешь что все реализации СМ это зеленые потоки.

I>Более того, в тасках она растёт в полный рост и решать её нужно руками, но попроще чем в APM. В Зеленых потоках её тоже надо решать, при чем еще проще, чем в тасках.

Ага, значит все таки таски это не зеленые потоки.

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

I>А что по твоему унутре зеленых потоков, чудеса и магия ? Там все те же самые continuation, отсюда возможность переключать выполнение ниток руками.

Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.

I>Если бы в С# был экспрешном и работал как yield в Питоне

Переведи на русский.

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

N>Что за "таски" в дотнете, не знаю

http://en.wikipedia.org/wiki/Task_Parallel_Library#Task_Parallel_Library

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

S>Попробуй перечитать свою постановку задачи. Чтоб далеко не лазил — вот цитата:
S>

S>А вот извраты FileStream.BeginRead в своём уме никто не использует
S> В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

S>и найди там слова "разделяемый ресурс".

Я выделил. Здесь вроде понятно, что переменную нужно читать-писать асинхронными методами.

S>Тем не менее, если так хочется ресурс<>последовательность, рекомендую посмотреть в сторону rx. .FromAsync() там тоже есть, остальное элементарно.

Нет, не элементарно. FromAsync ничего не меняет.

См код который я показал НС

когда выполняется несколько операций одновременно, всилу асинхроннщины в IOCP, есть временные промежутки между write и read одной операции.
read вернул 5, write должен модифицировать именно это значение — инвариант. Но в силу наличия промежутка из за шедулинга, одна из операций успеет чего нибудь сделать — или прочитать, или записать. итого, write нарушает инвариант.

вот эта хрень растет из IOCP, а ты мне хотел показать, как синхронный код выполнить асинхронно, т.е. исключить IOCP.

Если тебе это непонятно — тренируйся.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

НС>Они не просто могут, они справляются.

Они именно её и используют, в т.ч..

I>> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.

НС>Нет. Continuation там для описания зависимостей, а не для многозадачности.



continuation нужны для того, что бы работали операции которые завязаны например на тот же таймер. По другому это в принципе невозможно.

>Многозадачность там обычная, вытесняющая.

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

Смотри внимательно:

static void Main(string[] args)
        {
            for (int i = 0; i < 100; i++)
            {
                Operation();
            }

            Console.ReadLine();
        }

        static async void Operation()
        {
            var value = await Read();

            Write(value + 1);
        }

        private static async Task<int> Read()
        {
            await Task.Delay(Delay);

            return _resource;
        }

        private static async void Write(int value)
        {
            await Task.Delay(Delay);

            _resource = value;
            Console.WriteLine(_resource);
        }

        private static int Delay {
            get {
                return (int) ((Rnd.Next() / (double)int.MaxValue) * 1000);
            }
        }

        private static int _resource = 0;
        static Random Rnd = new Random();

Надо объяснять, что Operation асинхронная ?
Надо объяснять, что это кооперативная многозадачность ?

Вот этот пример, кстати говоря, наиболее близок к тому, как работает IOCP. Операция сначала шедулится и только потом, через некоторое время реально выполняется.

Теперь покажи ,как ты эту асинхронщину исправишь своими мега-тасками.

НС>Ты ваот что путаешь, похоже: зеленые потоки могут использоваться в качестве варианта реализации continuation monad практически в лоб. Таски же реализуют СМ по другому. Ты же думаешь что все реализации СМ это зеленые потоки.

ты лучше подумай, для чего нужен event loop для async-await.

I>>Более того, в тасках она растёт в полный рост и решать её нужно руками, но попроще чем в APM. В Зеленых потоках её тоже надо решать, при чем еще проще, чем в тасках.

НС>Ага, значит все таки таски это не зеленые потоки.

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

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

НС>>Они не просто могут, они справляются.
I>Они именно её и используют, в т.ч..

Нет. Никаких зеленых потоков внутри тасков нет. От слова совсем.

I>>> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.
НС>>Нет. Continuation там для описания зависимостей, а не для многозадачности.
I>continuation нужны для того, что бы работали операции которые завязаны например на тот же таймер.

Нет. Continuation описывают зависимости между тасками чтобы обеспечить правильный порядок их исполнения. Частный случай такой зависимости — фьючерсы.

>>Многозадачность там обычная, вытесняющая.
I>Многозадачность зависит не от тасков.

Зависит от конкретного таска. Но простейший таск, который создается вызовом Task.Run, использует многозадачность, обеспечиваемую ОС. Стандартные IO bound таски работают, опять же, через механизм ОС — IOCP. Никаких зеленых потоков в штатных реализациях тасков нет.

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

Нет.

class Program
{
    private static Task<int> MyTask()
    {
        return Task.Run(
            () =>
            {
                Thread.Sleep(100);
                return Thread.CurrentThread.ManagedThreadId;
            });
    }

    private async static void Do()
    {
        var id1 = await MyTask();
        var id2 = await MyTask();
        Console.WriteLine("id1 = " + id1);
        Console.WriteLine("id2 = " + id2);
    }

    static void Main()
    {
        Do();
        Console.Read();
    }
}

У меня выводит:

id1 = 3
id2 = 4

Кооперативная говоришь?

I>ты лучше подумай, для чего нужен event loop для async-await.

Не нужен, таски прекрасно работают и в консольных приложениях. Нужен для синхронизации в случае GUI.

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

Смысл фразы непонятен.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.

А эвентлуп каким то чудом узнает, что вон тот колбек он идет от этого таска, а не от того

Пиши еще

I>>Если бы в С# был экспрешном и работал как yield в Питоне

НС>Переведи на русский.

Здесь все просто

var x = yield(Task.SomeAwaitable())

получается тот же await

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет. Никаких зеленых потоков внутри тасков нет. От слова совсем.

А я и не говорил, что они унутре. Ты вероятно, с кем то еще споришь

НС>Нет. Continuation описывают зависимости между тасками чтобы обеспечить правильный порядок их исполнения. Частный случай такой зависимости — фьючерсы.

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

НС>Нет.
НС> Thread.Sleep(100);
НС>Кооперативная говоришь?

И по твоему Thread.Sleep асинхронный ? Да ты, я вижу, непростой

Замени его на Таймер, что бы получить асинхронность и объясни результаты.

А еще лучше прекратить валять дурака и запустить код, который я тебе дал

НС>Не нужен, таски прекрасно работают и в консольных приложениях. Нужен для синхронизации в случае GUI.

Ога. Это если ты Thread.Sleep вызываешь.

НС>Смысл фразы непонятен.

Я заметил это по Thread.Sleep

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Да не переключает в тасках никто выполнение нитей. Совсем. Пока конкретная таска выполняется, она владеет потоком ОС монопольно.

Как и зеленый поток, вообще говоря Выполнение ты сам переключаешь. Например, так —

var x = await Something(...)

await отдаёт управление шедулеру, а он сам решит, чего и когда продолжить.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Не знаю что у тебя там возникает, но таски прекрасно справляются без кооперативной многозадачности.
I>>Не могут они без этого справляться.
I>> Таски унутре continuation-based, то есть, практически кооперативная многозадачность.
НС>Нет. Continuation там для описания зависимостей, а не для многозадачности. Многозадачность там обычная, вытесняющая.

Я посмотрел ссылку, которую ты прислал, про TPL. И вижу следующее:

A Task Manager contains a global queue of Tasks, which are then executed. In addition, it also encapsulates multiple threads onto which the Tasks are executed. By default, as many threads as there are processors (or processor cores) on the system are created, though this number may be manually modified. Each thread is associated with a thread-specific queue of Tasks. When idle, each thread picks up a batch of Tasks and puts them on its local queue, where they are then executed, one by one. If the global queue is empty, a thread will look for Tasks in the queues of its peers, and will take the Tasks which have been in the queue the longest (task stealing).

Исходя из неё, в этом средстве нет никакого варианта переключиться на другую задачу, если текущая ушла в блокирующее ожидание. Да, ОС переключит в этом случае на другую нить, но текущая будет всё равно занята. А если все нити (как написано, по умолчанию их количество равно количеству логических процессоров) будут таким образом заняты, весь task manager остановится. То есть всё это не более чем пул нитей с каким-то хилым закосом под человеческую морду.
Да, я здесь сужу именно по отсутствию информации про такие механизмы в статье. Но косвенным подтверждением является то, что статья в MSDN Magazine разливается соловьём про разные вычисления (CPU-bound) и ни слова про ввод-вывод, зато явно что это "пул с возможностью остановить и подождать". Ещё одно подтверждение — логика планирования — каждый забирает по пачке задач, но потом могут обмениваться очередями — однозначный расчёт на потенциально долгое выполнение одной задачи.

А в этом случае "таски прекрасно справляются без кооперативной многозадачности" уже некорректно, как только мы говорим про I/O. Там, где на IOCP и аналогах можно зашедулить пару тысяч одновременных I/O операций, тут ты это не сделаешь в принципе.

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

I>>>А вот извраты FileStream.BeginRead в своём уме никто не использует
НС>>А что там такого извратного?
I>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.

Ну а откуда предложение делать через одну переменную? Пусть будут хотя бы две
А так — да, писали в таком стиле. Более того, кто пишет на каком-нибудь Erlang иначе и не работает, потому что в языке вместо циклов рекурсия Хотя там обычно преимущество — что действия типа file:read(), gen_server:call() шедулят переключение с текущего процесса (green thread в терминах более распространённых), но возвращают в него же с результатом. Но есть и такие, которые могут только вызвать callback, которому нужно передать полный контекст. Вот тогда начинается рисование FSM.

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

Почему проще?

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

S>Напомню контекст, твой прошлый пост:
S>

S>А вот извраты FileStream.BeginRead в своём уме никто не использует
S>В кратце — асинхронная цепочка в таком вот стиле это АДЪ. попробуй написать скажем сумму последовательности, если у тебя одна переменная и методы навроде BeginRead, BeginWrite и тд.
S>Внезапно, даже в однопоточной модели возникают гонки в силу кооперативной многозадачности. В зеленых потоках эту проблему проще контролировать.

S>Можешь объяснить, при чём тут вообще кооперативная многозадачность и какой магией зелёные потоки будут отличаться от тасков?

См. мой предыдущий ответ. С тасками названного тобой образца заполнение всех нитей ожиданием I/O заблокирует пул в целом. Более того, ожидание чего-то через Task.Wait() может дать такой же результат, если нет свободных нитей, и поставленная в очередь задача не может из-за этого выполниться. Если егойный task manager решает это временным порождением новых нитей, то это грязный хак, не отменяющий порочность механизма (и ещё неизвестно, сколько ему надо, чтобы понять ситуацию). Если же он в состоянии при любом переходе исполняющей нити в ожидание переключать эту нить на другую задачу — то фактически мы имеем подложкой под task manager — не OS threads, а green threads.

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

S>Микрософт всунула в таски все что только смогла придумать
S>разработчики в МС сами не понимают, как работают таски
S>когда вижла зависает и сообщает что чем то занята, пудозреваю, это те же таски

S>причём все, такое впечатление, только что из пальца высосан. И делаешь вывод: у тасков есть проблемы.

А что в таком случае происходит, когда "вижла" зависает? (BTW, что такое "вижла"? Visual Studio или что-то другое? я вашего жаргона не знаю)

I>>Ты немного додумал за меня, процентов на 90. Вместо "ExecutionContext не нужен" было " не надо поддержвать сто тыщ пиццот разных контекстов и потоковых моделей"
S>В тасках ровно одна модель. За неё прячется практически что угодно — от обычных потоков до акторов и динамического раскидывания вызовов по кластеру. Только не надо начинать за "это всё не нужно"

Мнэээ... там таки есть гарантия, что спящая в ожидании задача освободит тред, или нет?
Если её нет на распространённой платформе — то о чём говорить?

I>>Таски нельзя отладить — речь была про APM-модель. Будет гаранировано АДЪ. Собственно, с тасками у микрософта пока что не сильно лучше.
S>Ты 100% не использовал Parallel Stacks Window. Т.е. с тасками по сути не работал, о чём и было сказано выше. Про отладку в VS 1013 с поддержкой awiat и прочих плюшек даже начинать не буду.

Простите, а с каких это пор неиспользование возможности _отладчика_ для "тасков" означает неработу с ними "по сути"?

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

I>Без зеленых потоков получится моделька навроде той что в nginx. Разработчиков такого уровня в каждом регионе по пару штук.

nginx в общем-то очень простой, хоть и объёмный. Пул тредов с FSM в каждой плюс немного мелких плюшек вокруг (например, файловый AIO делать через ядерный AIO или как?) Хотя это я, может, недооцениваю сложность подхода через FSM для прогерских ширнармасс. Мне было бы в разы сложнее поднять такой проект в целом и не обломиться, чем сделать именно такую реализацию на FSM и IOCP-с-аналогами, пока есть время и деньги

Если уж искать пример сложной логики, которую фиг так прямо переложишь на IOCP/epoll/etc. это работа с БД, драйвер FS и тому подобное, где развилок логики чуть более чем дохрена и контексты значительно более сложные, а клиентов не тысячи. По тому, что я вижу на СУБД, они делают сессии целыми нитями или даже процессами (под Unix, где это относительно дёшево).

BTW если ты вспомнил про nginx — вспомни и историю http cache "Oops!" (разработка одесской команды под руководством Игоря Хасилева). У них была организация — одна нить на клиента (в отличие от конкурента squid, который стоял на poll+FSM). Но у них были сплошь Sun с соляркой, где нити поддерживались честно и их можно было плодить. Ни Linux ни FreeBSD тогда (считаем, 1997-2002) нормальных нитей не держали, и на них Oops не выживал. А с увеличением количества клиентов (был у нас такой безумный период, когда внешних каналов почти не было — их только после оранжевой революции появилось, из-за изгнания старых взяточников из НКРЗ; прокси были тогда крайне важны) — и Oops перестал держать, в то время как squid справлялся, особенно с новыми плюшками вроде cache peering.