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

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

S>>>>Достаточно обрабатывать события асинхронно — например, вытащить обработку в фоновый поток, что не представляет особых проблем ещё с первого фреймворка.
ARK>>>А это что, не распараллелливание?
S>>Без обид, но у вас все баззворды собраны в одну кучу

ARK>Асинхронность по определению означает наличие второго потока исполнения (реального или виртуального — неважно).
Да ладно Реализации на локальной очереди, через петлю обработки сообщений, через подписку на IObservable, через таски, IO completition ports etc обходятся ровно одной абстракцией — continuation-passing. Зачем здесь вводить понятие "потока исполнения"?

Особенно если учитывать что всё вышеперечисленное протаскивает за собой ExecutionContext, т.е. с логической точки зрения поток исполнения остаётся один.

ARK>В принципе да, но одно всегда влечет другое.
Нет. Асинхронность не означает параллельности и наоборот. Я могу преспокойно написать асинхронный метод, который будет тупо вызывать переданный ему callback и передавать ему вычисленное значение без запуска в фоновом потоке. И да, с концептуальной точки зрения этот код будет асинхронным: в следующей версии не нарушая контракта вычисления будут запущены в фоне или вообще уедут в облако.

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

S>>Ещё можно глянуть вот эти статьи — первое найденное, подробно не копался.
ARK>Спасибо, гляну из дома. Хотя и так ясно, что там даже близко нет того, о чем я говорю.
Конечно нет, там всё на банальном моделировании системы частиц. В голове крутится, что кто-то где-то пытался пойти дальше и скрестить модель акторов, конечные автоматы и обработку матриц на GPU, но сейчас хоть убей деталей не вспомню

ARK>Топик про управляющие конструкции в языках программирования. Не про мейнстрим-языки и не про вещи, реализуемые на типовых пользовательских компьютерах.
Ок, тогда встречный вопрос:
кому интересны отдельные конструкции, которые малоприменимы в мейнстриме? Повторюсь, для таких вещей лучше взять специализированный язык с подходящей моделью вычислений и не пытаться впихнуть всё в несчастный шарп

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

ARK>>Асинхронность по определению означает наличие второго потока исполнения (реального или виртуального — неважно).
S>Да ладно Реализации на локальной очереди, через петлю обработки сообщений, через подписку на IObservable, через таски, IO completition ports etc обходятся ровно одной абстракцией — continuation-passing. Зачем здесь вводить понятие "потока исполнения"?

Хм, вообще-то continuation-passing не имеет ничего общего с асинхронностью. Ортогональные, как вы говорите, понятия.
В википедии обнаружить чего-то асинхронное в соответствующей статье мне тоже не удалось: http://en.wikipedia.org/wiki/Continuation-passing_style

ARK>>В принципе да, но одно всегда влечет другое.
S>Нет. Асинхронность не означает параллельности и наоборот.

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

S>Я могу преспокойно написать асинхронный метод, который будет тупо вызывать переданный ему callback и передавать ему вычисленное значение без запуска в фоновом потоке. И да, с концептуальной точки зрения этот код будет асинхронным: в следующей версии не нарушая контракта вычисления будут запущены в фоне или вообще уедут в облако.

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

S>Аналогично, Parallel.For может развернуть цикл в несколько потоков, динамически раскидывать по потокам пачки элементов из исходной последовательности, запулить всё в один поток или замусорить очередь таскпула. С концептуальной точки зрения по прежнему ничего не поменяется — мы отдаём управление циклом на откуп рантайму в обмен на возможность загрузить все ядра CPU.

А кто сказал, что Parallel.For — "параллельный" метод?
Вот я напишу метод MamoyKlyanusYaParallelniy — вы его тоже будете считать параллельным?
Надо знать семантику метода. Если он выполняется в другом потоке — значит параллельный. Если в текущем — значит не параллельный. (А если он запускается в другом потоке управления, то скорее всего он будет и асинхронным, хотя возможен и бесполезный синхронный вариант )
"С концептуальной точки зрения", как вы говорите, ваш Parallel.For просто выполняет переданный ему делегат — и все.

ARK>>Топик про управляющие конструкции в языках программирования. Не про мейнстрим-языки и не про вещи, реализуемые на типовых пользовательских компьютерах.
S>Ок, тогда встречный вопрос:
S>кому интересны отдельные конструкции, которые малоприменимы в мейнстриме?

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

S>Повторюсь, для таких вещей лучше взять специализированный язык с подходящей моделью вычислений и не пытаться впихнуть всё в несчастный шарп

Шарп да, лопнет скоро. От всякого мусора типа yield return, dynamic и partial methods. С каждой версией язык становится все более эклектичен.