VD>Итак, чтение из файла в Виндовс действительно может делаться ассинхронно если исползуется Overlapped I/O. При этом внутри Виндовс параллельность чтения осуществляется довольно сложными механизмами где без рабочих потоков вряд ли можно обойнись.

Некоторые операции выполняются без потоков. Для драйверов есть традиция выполняться определённый код в контексте первого попавшегося потока.

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

Впрочем, другая часть кода драйверов ввода-вывода выполняется в так называемых "системных" потоках, то есть в отдельном пуле потоков в процессе System (его можно увидеть в Task Manager рядом с System Idle).


Мало того, внутри архитектуры NT (Windows NT, 2000, XP, 2003) операции ввода-вывода всегда выполняются асинхронно. Чтобы мы там не указывали в FileStream-конструкторе или в системном вызове CreateFile. Для чтения из файла создаётся определённым образом сформатированый IRP-запрос драйверу, и этот запрос "путешествует" и выполняется разными частями ОС асинхронно. Фактически, в процессе одной операции чтения запрос может обрабатываться в одном, другом, третьем системном потоке — как получится.

Для более верхнего уровня — Win32 API или FileStream — вся эта асинхронность скрыта, и для программиста есть как правило два способа вызова: синхронный и асинхронный. Но всё равно в обоих случаях реальное выполнение будет происходить асинхронно с использованием как специально выделеных системных потоков, так и иногда "первых попавшихся" пользовательских. Просто синхронная работа как бы "эмулируется" на определённом низком уровне API.


Для того, чтобы жизнь мёдом не казалась, можно упомянуть ещё такую системную концепцию из области драйверов файловых систем, как Fast IO. Она тоже относится к оптимизации синхронности-асинхронности, как раз для случая быстрых "маленьких" операций выполняя их "более синхронно".

* * *

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

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

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

Tom>Ты хоть сам понял что сказал? Асинхронный по своей сути означает выполнение одновременно вызванного метода и чего то ещё, для этого нужно 2 потока.
Асинхронный вызов означает что вызывающий поток не ожидает результат вызова и тогда вызов асинхронен относительно вызывающего потока.

С уважением, Gleb.

Здравствуйте, <Аноним>, Вы писали:
А>Так вам не кажется, что слово "separately" это латентно "in some other thread"?
Нет. Не надо изобретать скрытый смысл там, где его нету. separately ортогонально in some other thread.
Например, во время обработки какого-то сообщения я вызываю Invalidate. Как уже сказали, я не дожидаюсь окночания операции перерисовки, то есть вызов — асинхронный.
Пример 2: делаю PostThreadMessage в другой поток и иду дальше. Здесь асинхронный вызов обслуживается другим потоком.
Пример 3: Я делаю SendMessage в окно другого потока. Работу выполняет совершенно другой поток, но вызов — синхронный! Потому, что я дожидаюсь окончания обработки.

Здравствуйте, Аноним, Вы писали:

В данном случае mihailik прав. Единственное с чем могу не согласиться, это "как правило". Асинхронность и многопотость это разные термины. Асинхронность значит что вызывающая последовательность выполнения не будет ожидать окончания выполнения вызова. Потоки это лишь один из способов выполнения данного требования. Это может быть создание нового потока(или если вам угодно, использование потока из пула), использования уже существующего, или использование текущего. Например, операция Invalidate(перерисовка контрола или формы) операция асинхронная. И если вызывающий поток главный для программы, то это выливается в постановку перерисовки в очередь(стандартная очередь сообщений Win32) в текущем потоке. Если вызывающий поток не главный для программы, то он должен использовать BeginInvoke, который поставит в команду в очередь главного окна. То есть способов использования асинхронности очень много, и они не обязательно должны иметь дополнительный поток.

С уважением, Gleb.

Здравствуйте, <Аноним>, Вы писали:

А>По мотивам
А>http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=8a4d8bd1-a926-4d19-83c7-f126f9cb14de
А>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем."
А>и частично
А>http://rsdn.ru/Forum/?mid=1208906

Автор: mihailik
Дата: 06.06.05

А>Существует ли пример, когда асинхронная операция выполняется в вызывающем потоке, причем оправданно? (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)
А>Собственно смущает статус MVP человека, написавшего это.

Асинхронность ассинхронности резнь. Полноценная ассинхронность конечно без многопоточности недоступна. Однако в виндовс есть поддержка так называемоей кооперативной многопоточности. Еще до выхода NT и 95-ых виндовс предоставляла эту возможность. Суть ее очень проста. Интерактивное приложение не все время потребляет процессорное время. Более того, 99% времени оно попросту спит. "Спит" — означает что приложение передает управление ОС и ждет от нее отклика. Для этого приложение вызвает АПИ-шный метод GetMessage(). Если в очреди потока помещается сообщение ОС передает его приложению возвращая управление из GetMessage().

Так вот на этом механизме можно реализовать ассинхронность.
Вариатны есть следующие:
1. Создать таймер. При каждом его срабатывании Виндовс будет помещать в очередь потока сообщение WM_TIMER обрабатывая которое приложение может делать некоторые действия в основном GUI-потоке. Если это действие не занимает много времени (ну, например, обровление отображаемой информации), то создается эллюзия многопоточной работы. Обрабатывается WM_TIMER только когда в очереди нет других собщений и в самую последнюю очередь (грубо говоря вытесняется).
2. Можно послать себе же ассинхронное сообщение. Для этого нужно использовать функцию PostMessage. Этот метод помещает сообщение в очередь потока, но при этом сразу же возвращает уравление. К тому же сообщения посланные этим методом имеют более низкий приоритет и разбираются после того как будут разобраны все синхронные сообщения.

Собственно все эти способы точно так же доступны в WinForms-приложениях. Так что организовать ассинхронность, хотя и не полноценную, таки можно и имея только один поток. Так у класса Control есть методы BeginInvoke которые реализован какраз через PostMessage. Ну, и само собой есть контрол основанный на виндовом таймере.


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

ЗЫ

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

Собственно, что трепаться то? Проще проверить.
Делаем по бырому тестик:

using System;
using System.Threading;
using System.Text;
using System.IO;

class Program
{
    static void Main(string[] args)
    {
        using (FileStream fs = File.OpenRead(@"C:\boot.ini"))
        {
            Console.WriteLine("Main:");
            Console.WriteLine("    IsThreadPoolThread: "
                + Thread.CurrentThread.IsThreadPoolThread);
            Console.WriteLine("    Current Thread ID: "
            + AppDomain.GetCurrentThreadId());

            byte[] array = new byte[fs.Length];
            IAsyncResult ar1 = fs.BeginRead(array, 0, array.Length,
                delegate(IAsyncResult ar2)
                {
                    Console.WriteLine("Callback:");
                    Console.WriteLine("    IsThreadPoolThread: "
                        + Thread.CurrentThread.IsThreadPoolThread);
                    Console.WriteLine("    Current Thread ID: "
                    + AppDomain.GetCurrentThreadId());
                }, null);

            while (!ar1.IsCompleted)
                Thread.Sleep(100);

            Console.WriteLine();
            Console.WriteLine();
            Console.WriteLine("Считанные данные:");
            Console.WriteLine(Encoding.Default.GetString(array));
        } 
    }
}

и запускаем... у меня он вывел:

Main:
        IsThreadPoolThread: False
        Current Thread ID: 2584
Callback:
        IsThreadPoolThread: True
        Current Thread ID: 2920


Считанные данные:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(3)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecu
te=OptIn
multi(0)disk(0)rdisk(0)partition(4)\WINDOWS="Windows XP Professional x64 Edition" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect

Из чего можно сделать вывод:
1. Обратный вызов делается в другом потоке.
2. Это поток из дотнетного пула, так что скорее всего ассинхронность реализована в данном случае в недрах дотнета.

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

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

Tom>Музчина я говорю не про асинхронность сферического коня в вакуме а про асинхронный вызов метода, который подразумевает выполнение в отдельном потоке.
Специально в MSDN нашел, не поленился:

Asynchronous call
A call to a function that is executed separately so that the caller can continue processing instructions without waiting for the function to return. Contrast with Synchronous call.

С уважением, Gleb.
ЗЫ надеюсь это можно считать окончанием флейма

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

O>Здравствуйте, <Аноним>, Вы писали:

А>>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем."
А>>и частично
А>>http://rsdn.ru/Forum/?mid=1208906

Автор: mihailik
Дата: 06.06.05

O>Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода метода при асинхронном вызове происходит всегда в другом потоке — не в том, из которого вызов был произведён. Другое дело, что поток для асинхронного вызова берётся из пула потоков — возможно, поэтому на деле используется пара потоков для большого количества асинхронных вызовов.
Так и есть, поток для исполнения кода вызываемого асинхронно берется из пула, НО это уже как минимум 2 потока — вызывающий и взятый из пула.

Hello, "Andrbig"
>
> У меня Beginread на который ссылался Михайлик, вообще не имеет ничего
> общего с асинхронностью. Все происходит тупо в вызывающем потоке, т.е.
> как обычная синхронная операция. Так что к вопросу автора я добавлю свой —
> кто-нить может привести код с асинхронной работой
> FileStream.BeginRead?

BeginRead/BeginWrite мегабайта данных на дискетку.

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

TK>Hello,
>>
>> TK>А зачем ей это?
>> Ну если рассматривать ОС как черный ящик по отношению к CLR то Ваша точка
>> зрения имеет право на существование.

TK>Думаю, что более правильно будет "если рассматривать CLR как черный ящик по
TK>отношению к программисту то точка зрения что будут создаватся доп. потоки
TK>имеет право на существование". Что касается CLR то, OC для нее черным ящиком
TK>не является и это активно используется.

То есть вы считаете что ОС не создает потока для "Заполнения переданного буфера и уведомления о завершении"?

Hello, "Tom"
> Ты хоть сам понял что сказал? Асинхронный по своей сути означает
> выполнение одновременно вызванного метода и чего то ещё, для этого нужно 2
> потока.

Какая-то у тебя каша в голове... Когда нибудь асинхронное плавание по
телеку видел?
Вот картинка для лучшей демонстрации
синхронное плавание.
Вот из толкового словарика: синхронный ‘совпадающий по времени’ Syn:
одновременный, параллельный. Lingvo. А вот асинхронный это как раз
наоборот

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

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

TK>Вот только не надо все в одну кучу мешать. Пример с асинхронными операциями
TK>подразумевает 2 принципиально различных действия (в одном задействован
TK>процессор а в другом жесткий диск).
Ну не может жесткий диск работать без хотя бы минимального управления тем, что в свою очередь не может работать без потоков.

TK>Переводя на пловцов это будет "пока ты тут плавал, твою машину со стоянки
TK>...сперли".
Так кто спер? =) Потоки не иначе.

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

TK>Hello,

>> TK>О завершении операции сигнализирует объект ядра. Разве сложно MSDN
>> почитать?
>> А объект ядра живет отдельно вне потоков? Разве сложно задуматься?

TK>Мало того, объекты ядра живут вне процессов
Процессы тут вообще не причем
А поточно любое действие при достаточной его детализации.

Здравствуйте, Аноним, Вы писали:

TK>>О завершении операции сигнализирует объект ядра. Разве сложно MSDN почитать?
А>А объект ядра живет отдельно вне потоков? Разве сложно задуматься?
Потоки это не просто кванты времени выделенные определенному потоку команд. Поток имеет достаточно большое и интересное количество аттрибутов(например дескритор доступа) и свойств. Потоков в режиме ядра как таковых нет и быть не может.
Как он определяет что закончилась перекачка данных, это его личное дело. Я не знаю, и знать не хочу. У меня, во времена MSDOS, дополнительного потока не было, как не было и самих потоков как таковых. Результат операции определялся по порту микросхемы DMA.

С уважением, Gleb.

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

GZ>Здравствуйте, Аноним, Вы писали:

TK>>>О завершении операции сигнализирует объект ядра. Разве сложно MSDN почитать?
А>>А объект ядра живет отдельно вне потоков? Разве сложно задуматься?
GZ> Потоков в режиме ядра как таковых нет и быть не может.
Так вот они есть. Просто спят (находятся в состоянии ожидания).

Hello, "Tom"
> ТК ты пойми метод, он тоже ведь на коня в вакуме не очень похож, ему что
> бы выполняться нужен поток,
> и если это не текущий поток — то какой то другой

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

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


GZ>Как он определяет что закончилась перекачка данных, это его личное дело. Я не знаю, и знать не хочу. У меня, во времена MSDOS, дополнительного потока не было, как не было и самих потоков как таковых. Результат операции определялся по порту микросхемы DMA.

Я скажу как — поток банально ждет (спит), но поверьте — это не тот поток, который в это время усиленно трудится над операциями, которые следуют после вызова асинхронной операции ввода-вывода.

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

GZ>Здравствуйте, Аноним, Вы писали:

GZ>>>

GZ>>>Asynchronous call
GZ>>>A call to a function that is executed separately so that the caller can continue processing instructions without waiting for the function to return. Contrast with Synchronous call.

GZ>>>ЗЫ надеюсь это можно считать окончанием флейма
А>>Так вам не кажется, что слово "separately" это латентно "in some other thread"?
GZ>Перевожу для тех, кто по буржуйски не балакает. Здесь написано:
GZ>

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

Перевожу для тех кто не вникает в брутальные фразы и думает что кто-то по буржуйски не балакает.

"Так вам не кажется, что слово "separately" это латентно "in some other thread"?"
=
"Так вам не кажется, что слово "раздельно" подразумевает "в другом потоке"?"

латентно — скрыто, неявно

Hello, "Tom"

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

О, новый термин

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

Здравствуйте, Аноним, Вы писали:

А>латентно — скрыто, неявно
Oops. Немного ошибся. Только смысл фразы не меняется. Никаких упоминаний потоков здесь нет, и не может быть. Потоки — это всего лишь некоторые способы обеспечения асинхронности. Но не единственные. Тот кто скажет что Control.BeginInvoke или PostMessage — синхронные, то может в меня бросить камень.

С уважением, Gleb.

GZ>С уважением, Gleb.

Можешь ответить на вопрос?

"Так вам не кажется, что слово "separately" это латентно "in some other thread"?"

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

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

GZ>>>С уважением, Gleb.

Tom>>Можешь ответить на вопрос?

Tom>>"Так вам не кажется, что слово "separately" это латентно "in some other thread"?"
GZ>Не вырывай из контекста. "separatly so that". Условие separatly построено строго. И никаких намеков на параллельное выполнение.

Хорошо, тогда скажи к чему болл применимо высказывание "...separatly so that...":
1. in the same thread
2. in the another thread

Hello, "Tom"
>
> Отложенный в данном контексте отличается от асинхронного тем, что
> отложенный будет выполняться в текущем потоке.
>

ок. добъем терминологию Как называется общий механизм абстрагирующий
технологию вызова от конкретной реализации (отложенная/асинхронная в "твоем
понятии" )?

> Давай так, асинхронный вызов он асинхронен чему? И чему он будет
> асинхронен если выполняется
> в текущем же потоке

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

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

TK>От себя могу сказать, что вызов делегата через BeginInvoke тоже ничего не
TK>гарантирует.

Ну, он точно гарантирует запуск в другом потоке. Другое дело, что начиная со второго фрэймворка это может быть "легкий поток", т.е. по сути файбер. А файберы явно не катят в качестве оповещения о завершении операции.

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

S>Неоднозначная трактовка лпределений говорит об их недостаточной формальности

или о богатом воображении читающих.

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

По мотивам
http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=8a4d8bd1-a926-4d19-83c7-f126f9cb14de
Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем."
и частично
http://rsdn.ru/Forum/?mid=1208906

Автор: mihailik
Дата: 06.06.05

Существует ли пример, когда асинхронная операция выполняется в вызывающем потоке, причем оправданно? (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)
Собственно смущает статус MVP человека, написавшего это.

Здравствуйте, <Аноним>, Вы писали:

А>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем."
А>и частично
А>http://rsdn.ru/Forum/?mid=1208906

Автор: mihailik
Дата: 06.06.05

Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода метода при асинхронном вызове происходит всегда в другом потоке — не в том, из которого вызов был произведён. Другое дело, что поток для асинхронного вызова берётся из пула потоков — возможно, поэтому на деле используется пара потоков для большого количества асинхронных вызовов.

Пример: асинхронная работа с СОМ портом, пока он там себе читает возможно нет необходимости все тормозить и ждать результата.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Аноним, Вы писали:

А>По мотивам
А>http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=8a4d8bd1-a926-4d19-83c7-f126f9cb14de
А>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем."
А>и частично
А>http://rsdn.ru/Forum/?mid=1208906

Автор: mihailik
Дата: 06.06.05

А>Существует ли пример, когда асинхронная операция выполняется в вызывающем потоке, причем оправданно? (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)

У меня Beginread на который ссылался Михайлик, вообще не имеет ничего общего с асинхронностью. Все происходит тупо в вызывающем потоке, т.е. как обычная синхронная операция. Так что к вопросу автора я добавлю свой — кто-нить может привести код с асинхронной работой FileStream.BeginRead?

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

ALV>Пример: асинхронная работа с СОМ портом, пока он там себе читает возможно нет необходимости все тормозить и ждать результата.

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

Hello, "Oyster"
>
> Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода
> метода при асинхронном вызове происходит всегда в другом потоке — не в
> том, из которого вызов был произведён.

Все зависит от реализации. Есть случаи когда это не так.

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

Не надо путать асинхронный вызов чего либо (например делегата) и асинхронный
ввод/вывод. Например, асинхронное чтение файла, создания дополнительного
потока не требует. Стоит почитать MSDN по словам overlapped I/O

Hello,
> И что? Чтение данных и код после вызова асинхронного чтнеия данных будут
> исполняться в одном потоке?

Нет. Заполнение переданного буфера и уведомление о завершении возмет на себя
операционная система.

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

TK>Не надо путать асинхронный вызов чего либо (например делегата) и асинхронный
TK>ввод/вывод. Например, асинхронное чтение файла, создания дополнительного
TK>потока не требует. Стоит почитать MSDN по словам overlapped I/O

[самокритика]
"Иногда лучше жевать, чем говорить"...
[/самокритика]

Hello,

> O>Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода
> метода при асинхронном вызове происходит всегда в другом потоке — не в
> том, из которого вызов был произведён. Другое дело, что поток для
> асинхронного вызова берётся из пула потоков — возможно, поэтому на деле
> используется пара потоков для большого количества асинхронных вызовов.
> Так и есть, поток для исполнения кода вызываемого асинхронно берется из
> пула, НО это уже как минимум 2 потока — вызывающий и взятый из пула.

Ничего там из пула не берется.

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

TK>Hello,
>> И что? Чтение данных и код после вызова асинхронного чтнеия данных будут
>> исполняться в одном потоке?

TK>Нет. Заполнение переданного буфера и уведомление о завершении возмет на себя
TK>операционная система.
А для этого она не создаст новый поток?

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


>> Так и есть, поток для исполнения кода вызываемого асинхронно берется из
>> пула, НО это уже как минимум 2 потока — вызывающий и взятый из пула.

TK>Ничего там из пула не берется.

If the BeginInvoke method is called, the common language runtime will queue the request and return immediately to the caller. The target method will be called on a thread from the thread pool. The original thread, which submitted the request, is free to continue executing in parallel to the target method, which is running on a thread pool thread.

Hello,
>
> TK>Нет. Заполнение переданного буфера и уведомление о завершении возмет на
> себя
> TK>операционная система.
> А для этого она не создаст новый поток?

А зачем ей это?

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

TK>BeginRead/BeginWrite мегабайта данных на дискетку.

Соответственно добавлю цитату из MSDN (FileStream.BeginRead):

On Windows, all I/O operations smaller than 64 KB will complete synchronously for better performance. Asynchronous I/O might hinder performance for buffer sizes smaller than 64 KB.

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

TK>Hello,
>>
>> TK>Нет. Заполнение переданного буфера и уведомление о завершении возмет на
>> себя
>> TK>операционная система.
>> А для этого она не создаст новый поток?

TK>А зачем ей это?
Ну если рассматривать ОС как черный ящик по отношению к CLR то Ваша точка зрения имеет право на существование.

Hello,

> TK>Ничего там из пула не берется.
>
> [msdn]If the BeginInvoke method is called, the common language runtime
> will queue the request and return immediately to the caller. The target
> method will be called on a thread from the thread pool. The original
> thread, which submitted the request, is free to continue executing in
> parallel to the target method, which is running on a thread pool
> thread.[/msdn]

Свое понимание ситуации тоже хорошо иногда иметь Хотя, если это слишком
сложно то, стоит верить тому, что написано в MSDN. Обычно это правда в ~90%
слечаев...

Hello,
>
> TK>А зачем ей это?
> Ну если рассматривать ОС как черный ящик по отношению к CLR то Ваша точка
> зрения имеет право на существование.

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

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

TK>Hello,

>> TK>Ничего там из пула не берется.
>>
>> [msdn]If the BeginInvoke method is called, the common language runtime
>> will queue the request and return immediately to the caller. The target
>> method will be called on a thread from the thread pool. The original
>> thread, which submitted the request, is free to continue executing in
>> parallel to the target method, which is running on a thread pool
>> thread.[/msdn]

TK>Свое понимание ситуации тоже хорошо иногда иметь Хотя, если это слишком
TK>сложно то, стоит верить тому, что написано в MSDN. Обычно это правда в ~90%
TK>слечаев...
90% — это к чему?
1) В 90% случаев все-таки берется из пула?
2) В 10% случаев MSDN врет?
Если 1) то вы опровергаетет сами себя, если 2) то я бы скорректировал цифру до 1-2% и практически для каждого случая есть причина.

Здравствуйте, Аноним, Вы писали:

А>If the BeginInvoke method is called, the common language runtime will queue the request and return immediately to the caller. The target method will be called on a thread from the thread pool. The original thread, which submitted the request, is free to continue executing in parallel to the target method, which is running on a thread pool thread.
Это не есть верно в случае Control.BeginInvoke.

С уважением, Gleb.

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

GZ>Здравствуйте, Аноним, Вы писали:

А>>If the BeginInvoke method is called, the common language runtime will queue the request and return immediately to the caller. The target method will be called on a thread from the thread pool. The original thread, which submitted the request, is free to continue executing in parallel to the target method, which is running on a thread pool thread.
GZ>Это не есть верно в случае Control.BeginInvoke.

Согласен, но в любом случае "Executes the specified delegate asynchronously on the thread that the control's underlying handle was created on."

Здравствуйте, Аноним, Вы писали:

А>Согласен, но в любом случае "Executes the specified delegate asynchronously on the thread that the control's underlying handle was created on."
И чего? Ну вызывается в контексте потока в котором был вызван контрол. А если BeginInvoke вызван в самом этом потоке, то вызов кладется в очередь до лучших времен. Как только все сообщения обработаны, будут обрабатываться сообщения из этой очереди. То есть работа асинхронных вызовов в одном потоке.

С уважением, Gleb.

Здравствуйте, <Аноним>, Вы писали:

А>По мотивам
А>http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=8a4d8bd1-a926-4d19-83c7-f126f9cb14de
А>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем."
А>и частично
А>http://rsdn.ru/Forum/?mid=1208906

Автор: mihailik
Дата: 06.06.05

А>Существует ли пример, когда асинхронная операция выполняется в вызывающем потоке, причем оправданно? (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)
А>Собственно смущает статус MVP человека, написавшего это.

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

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

GZ>Здравствуйте, Аноним, Вы писали:

GZ>В данном случае mihailik прав. Единственное с чем могу не согласиться, это "как правило". Асинхронность и многопотость это разные термины. Асинхронность значит что вызывающая последовательность выполнения не будет ожидать окончания выполнения вызова. Потоки это лишь один из способов выполнения данного требования. Это может быть создание нового потока(или если вам угодно, использование потока из пула), использования уже существующего, или использование текущего. Например, операция Invalidate(перерисовка контрола или формы) операция асинхронная. И если вызывающий поток главный для программы, то это выливается в постановку перерисовки в очередь(стандартная очередь сообщений Win32) в текущем потоке. Если вызывающий поток не главный для программы, то он должен использовать BeginInvoke, который поставит в команду в очередь главного окна. То есть способов использования асинхронности очень много, и они не обязательно должны иметь дополнительный поток.

Стандартную очередь сообщений Win32 тоже кто-то обслуживает. Если будет это вызывающий поток после того как он выполнит основную нагрузку, то нарушается сформулированное мной условие (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно). Эффективно не значит красиво =)

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

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

Автор: GlebZ
Дата: 04.10.05

С уважением, Gleb.

Здравствуйте, Аноним, Вы писали:

А>Стандартную очередь сообщений Win32 тоже кто-то обслуживает.
Никто. Вся работа в одном потоке.

C уважением, Gleb.

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

GZ>Здравствуйте, Аноним, Вы писали:

А>>Согласен, но в любом случае "Executes the specified delegate asynchronously on the thread that the control's underlying handle was created on."
GZ>И чего? Ну вызывается в контексте потока в котором был вызван контрол. А если BeginInvoke вызван в самом этом потоке, то вызов кладется в очередь до лучших времен. Как только все сообщения обработаны, будут обрабатываться сообщения из этой очереди. То есть работа асинхронных вызовов в одном потоке.

Нарушается мое условие которое я поставил в первом сообщении топика "(Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)".

Hello, "GlebZ"
> Это не есть верно в случае Control.BeginInvoke.
>

От себя могу сказать, что вызов делегата через BeginInvoke тоже ничего не
гарантирует.

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

GZ>Здравствуйте, Аноним, Вы писали:

А>>Стандартную очередь сообщений Win32 тоже кто-то обслуживает.
GZ>Никто. Вся работа в одном потоке.
Я же написал выше:
"Если будет это вызывающий поток после того как он выполнит основную нагрузку, то нарушается сформулированное мной условие (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)."

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

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

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

Автор: GlebZ
Дата: 04.10.05

GZ>С уважением, Gleb.

То есть работа асинхронных вызовов в одном потоке.

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

То есть вы считаете что ОС не создает потока для "Заполнения переданного буфера и уведомления о завершении"?
----------------
ОС создаст, но вот уведомление о завершение обработает изначальный поток асинхронно. ИМХО автор подразумевал, что нет необходимости создавать много потоков и ручками их регулировать, а достаточно асинхронно дождаться ответа.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

TK>Hello, "GlebZ"
>> Это не есть верно в случае Control.BeginInvoke.
>>

TK>От себя могу сказать, что вызов делегата через BeginInvoke тоже ничего не
TK>гарантирует.
Так вы можете привести пример? (вызова делегата через BeginInvoke чтобы вызванная операция исполнялась в этом же потоке , причем эффективнее, чем если бы я вызвал ее синхронно).

Здравствуйте, Аноним, Вы писали:

А>Нарушается мое условие которое я поставил в первом сообщении топика "(Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)".
Тебе уже указали. В принципе, любая работа ввода-вывода с периферийного устройства. Копирование данных память-устройство происходит не через процессор, а через каналы DMA и не требуют потока. Заниматься такой фигней как ожидание, в это время смысла нет.
Что касается вышеуказанного(GDI). Операция перерисовки достаточно долгая операция по сравнению с другими. При разборе очереди, если определяется что существует еще WM_PAINT, то данный WM_PAINT пропускается. Используется только последний WM_PAINT в очереди.(поэтому ты мог заметить, что если что-то серьезное выполняется в основном потоке приложения, перерисовки картинки нет). То же самое происходит с WM_MOUSEMOVE. Бомбардировать приложение такими сообщениями дорого. Поэтому обрабатывается только последний WM_MOUSEMOVE. Собственно это тоже можно заметить визуально, при резком переносе окна — окно не переносится попиксельно.

С уважением, Gleb.

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

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

Tom>>Ты хоть сам понял что сказал? Асинхронный по своей сути означает выполнение одновременно вызванного метода и чего то ещё, для этого нужно 2 потока.
GZ>Асинхронный вызов означает что вызывающий поток не ожидает результат вызова и тогда вызов асинхронен относительно вызывающего потока.

В таком определении вызов недетерминирован в контексте завершения. Например в случае смерти (по любой причине) вызывающего потока с ним умрет и то действие которое он же должен был сделать асинхронно (если он же и вызывающий и выполняющий поток).
К тому же при совмещении ролей вызывающего и исполняющего одним потоком теоретически в общем случае возможна нормализация такого вызова в синхронный.

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

GZ>Здравствуйте, Аноним, Вы писали:

А>>Нарушается мое условие которое я поставил в первом сообщении топика "(Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)".
GZ>Тебе уже указали. В принципе, любая работа ввода-вывода с периферийного устройства. Копирование данных память-устройство происходит не через процессор, а через каналы DMA и не требуют потока. Заниматься такой фигней как ожидание, в это время смысла нет.
А уведомление вызывающего потока о завершении работы ввода-вывода создаст и отдаст тоже DMA канал?

Hello,

> GZ>Тебе уже указали. В принципе, любая работа ввода-вывода с периферийного
> устройства. Копирование данных память-устройство происходит не через
> процессор, а через каналы DMA и не требуют потока. Заниматься такой фигней
> как ожидание, в это время смысла нет.
> А уведомление вызывающего потока о завершении работы ввода-вывода создаст
> и отдаст тоже DMA канал?

О завершении операции сигнализирует объект ядра. Разве сложно MSDN почитать?

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

TK>Hello, "Tom"
>> Ты хоть сам понял что сказал? Асинхронный по своей сути означает
>> выполнение одновременно вызванного метода и чего то ещё, для этого нужно 2
>> потока.

TK>Какая-то у тебя каша в голове... Когда нибудь асинхронное плавание по
TK>телеку видел?
TK>Вот картинка для лучшей демонстрации
TK>синхронное плавание.
TK>Вот из толкового словарика: синхронный ‘совпадающий по времени’ Syn:
TK>одновременный, параллельный. Lingvo. А вот асинхронный это как раз
TK>наоборот
А ты когда нибудь видел по телеку пловца, который умудряется отплавать одновременно 2 различные художественные программы за время одной?

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

TK>Hello,

>> GZ>Тебе уже указали. В принципе, любая работа ввода-вывода с периферийного
>> устройства. Копирование данных память-устройство происходит не через
>> процессор, а через каналы DMA и не требуют потока. Заниматься такой фигней
>> как ожидание, в это время смысла нет.
>> А уведомление вызывающего потока о завершении работы ввода-вывода создаст
>> и отдаст тоже DMA канал?

TK>О завершении операции сигнализирует объект ядра. Разве сложно MSDN почитать?
А объект ядра живет отдельно вне потоков? Разве сложно задуматься?

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

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

Hello,

> TK>О завершении операции сигнализирует объект ядра. Разве сложно MSDN
> почитать?
> А объект ядра живет отдельно вне потоков? Разве сложно задуматься?

Мало того, объекты ядра живут вне процессов

Здравствуйте, Аноним, Вы писали:

А>По мотивам
А>http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=8a4d8bd1-a926-4d19-83c7-f126f9cb14de
А>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем."
А>и частично
А>http://rsdn.ru/Forum/?mid=1208906

Автор: mihailik
Дата: 06.06.05

А>Существует ли пример, когда асинхронная операция выполняется в вызывающем потоке, причем оправданно? (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)
А>Собственно смущает статус MVP человека, написавшего это.

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

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

P.S. Если будешь пробовать, обрати внимание, что абы где асинхронную операцию не запустить — надо брать соответствующий конструктор FileStream с указанием асинхронности. По умолчанию она отключена.

Hello, "Andrbig"

> P.S. Если будешь пробовать, обрати внимание, что абы где асинхронную
> операцию не запустить — надо брать соответствующий конструктор FileStream
> с указанием асинхронности. По умолчанию она отключена.

Вот видишь, разобрался таки

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

TK>Hello, "Tom"
>> Ты хоть сам понял что сказал? Асинхронный по своей сути означает
>> выполнение одновременно вызванного метода и чего то ещё, для этого нужно 2
>> потока.

TK>Какая-то у тебя каша в голове... Когда нибудь асинхронное плавание по
TK>телеку видел?
TK>Вот картинка для лучшей демонстрации
TK>синхронное плавание.
TK>Вот из толкового словарика: синхронный ‘совпадающий по времени’ Syn:
TK>одновременный, параллельный. Lingvo. А вот асинхронный это как раз
TK>наоборот

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

Hello,
> Процессы тут вообще не причем
> А поточно любое действие при достаточной его детализации.

Понятно. Завязываем

Hello, "Tom"
>
> Музчина я говорю не про асинхронность сферического коня в вакуме а про
> асинхронный вызов метода, который подразумевает выполнение в отдельном
> потоке.

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

Здравствуйте, Аноним, Вы писали:

А>Процессы тут вообще не причем
А>А поточно любое действие при достаточной его детализации.
Если тебе это уж очень интересно, то лучше посмотри какую нибудь литературку по процессорам, и узнай что такое прерывание(особенно аппаратное).

С уважением, Gleb.

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

TK>Hello,
>> Процессы тут вообще не причем
>> А поточно любое действие при достаточной его детализации.

TK>Понятно. Завязываем
Да уж, перепоточили. Тема ушла далековато.

TK>Только, наверное, будет правильнее: который, я подразумеваю, будет
TK>выполняться в отдельном потоке?
ТК ты пойми метод, он тоже ведь на коня в вакуме не очень похож, ему что бы выполняться нужен поток,
и если это не текущий поток — то какой то другой

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

GZ>Здравствуйте, Аноним, Вы писали:

А>>Процессы тут вообще не причем
А>>А поточно любое действие при достаточной его детализации.
GZ>Если тебе это уж очень интересно, то лучше посмотри какую нибудь литературку по процессорам, и узнай что такое прерывание(особенно аппаратное).

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

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

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

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

GZ>Специально в MSDN нашел, не поленился:
GZ>

GZ>Asynchronous call
GZ>A call to a function that is executed separately so that the caller can continue processing instructions without waiting for the function to return. Contrast with Synchronous call.

GZ>ЗЫ надеюсь это можно считать окончанием флейма
Так вам не кажется, что слово "separately" это латентно "in some other thread"?

Здравствуйте, Аноним, Вы писали:

GZ>>

GZ>>Asynchronous call
GZ>>A call to a function that is executed separately so that the caller can continue processing instructions without waiting for the function to return. Contrast with Synchronous call.

GZ>>ЗЫ надеюсь это можно считать окончанием флейма
А>Так вам не кажется, что слово "separately" это латентно "in some other thread"?
Перевожу для тех, кто по буржуйски не балакает. Здесь написано:

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

С уважением, Gleb.

Хотя тут обсуждался больше BeginRead для FileStream, наиболее наглядная выгода от асинхронности (по сравнению с многопоточностью) появляется в сетевых приложениях.

Для читающих по английски очень советую посмотреть в прошлом MSDN Magazine была классная статья об организации работы с сокетами в контексте многопоточного сервера. Там эти вопросы разбираются просто по косточкам. Но, на английском

Почему асинхронность так выгодна для сетевых работ? Потому, что сетевых клиентов может быть одновременно ОЧЕНЬ много! А скорость работы сети гарантировано черепашья.

Обрабатывать запросы в однопоточном режиме, по очереди уже никак не подоходит. А современные версии Windows не потянут десять тысяч потоков. Но зато в асинхронном режиме 10 тыс. пользователей вполне будут обрабатываться и "не жужжать".

P.S. Большое спасибо за скептицизм по отношению к статусу MVP. Побольше таких постов, чтобы нам в своём эмвипизме не замшеть

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

TK>Hello, "Tom"

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

TK>О, новый термин

TK>Давай поподробней про отложенные вызовы
TK>Чем отложенный вызов от асинхронного отличается? Можно рассмотреть на
TK>ситуации, когда я откладываю вызов на "после перезагрузки".

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

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

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

GZ>>С уважением, Gleb.

Tom>Можешь ответить на вопрос?

Tom>"Так вам не кажется, что слово "separately" это латентно "in some other thread"?"
Не вырывай из контекста. "separatly so that". Условие separatly построено строго. И никаких намеков на параллельное выполнение.

С уважением, Gleb.

TK>ок. добъем терминологию Как называется общий механизм абстрагирующий
TK>технологию вызова от конкретной реализации (отложенная/асинхронная в "твоем
TK>понятии" )?
ТК, с понятиями у меня как то не очень,
я понятия лучше тебе оставлю

>> Давай так, асинхронный вызов он асинхронен чему? И чему он будет
>> асинхронен если выполняется
>> в текущем же потоке

TK>Асинхронный вызов асинхронен к самому моменту вызова. т.е. вызов
TK>асинхронного метода не означает его мгновенного завершения. Зачем сюда надо
TK>обязательно приплетать потоки совершенно не понятно...

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

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

>> Давай так, асинхронный вызов он асинхронен чему? И чему он будет
>> асинхронен если выполняется
>> в текущем же потоке

TK>Асинхронный вызов асинхронен к самому моменту вызова. т.е. вызов
TK>асинхронного метода не означает его мгновенного завершения.
А вызов синхронного метода что означает его мгновенное завершение?

Hello, "Tom"
>
> Затем, что обычно реализуются асинхронные вызовы через выполнение этого
> самого вызова где то отдельно и это отдельно почти всегда есть поток.

ок. давай по пунктам.

1. Асинхронный ввод/вывод (конкретно ReadFileEx из WinAPI) создает отдельный
поток для выполнения чтения?

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

Tom>Хорошо, тогда скажи к чему болл применимо высказывание "...separatly so that...":
Tom>1. in the same thread
Tom>2. in the another thread
Да ни к чему из этого неприменимо. Ясно сказано — раздельно так, чтобы вызывающий мог продолжать выполнять инструкции без ожидания возврата функции. Если вызывающий поток ожидает возврата функции то это можно нельзя считать "раздельно". А если это не "раздельно" -> то это не асинхронный вызов. В какое время будет работать вызываемая функция — одновременно или после, несказано.
Плохо с понятиями, давай по коду. Надеюсь ты не будешь возражать что Control.BeginInvoke — асинхронен. Посмотрим на него на рефлектор.

//вызов BeginInvoke приводит к вызову этой функции с параметром synchronous=false
//вызов Invoke приводит к вызову этой функции с параметром synchronous=false
private object MarshaledInvoke(Control caller, Delegate method, object[] args, bool synchronous)
{
//скинуто как неинтересное
//..........
//скинуто как неинтересное
      bool flag1 = false;
//проверяем а не находимся ли в том же потоке в случае вызова Invoke
      if ((SafeNativeMethods.GetWindowThreadProcessId(new HandleRef(this, this.Handle), out num1) == SafeNativeMethods.GetCurrentThreadId()) && synchronous)
      {
            flag1 = true;
      }
//скинуто как неинтересное
//..........
//скинуто как неинтересное

      if (flag1)
      {
//выполняется только если мы уже находимся в потоке и это вызов Invoke
            this.InvokeMarshaledCallbacks();
      }
      else
      {
//если это вызов BeginInvoke или если это вызов Invoke и мы находимся в другом потоке  
            UnsafeNativeMethods.PostMessage(new HandleRef(this, this.Handle), Control.threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
      }
//главное отличие BeginInvoke от Invoke - мы здесь не дожидаемся а выходим
      if (!synchronous)
      {
            return entry1;
      }
//обеспечение синхронности вызова для Invoke
      if (!entry1.IsCompleted)
      {
            entry1.AsyncWaitHandle.WaitOne();
      }
      if (entry1.exception != null)
      {
            throw entry1.exception;
      }
      return entry1.retVal;
}

Если caller находится в другом потоке, то вызов Invoke и BeginInvoke — одинаковы. Только для BeginInvoke — важно выйти не узнавая, выполнилась ли эта процедура, или нет.
Если caller находится в том-же потоке, то делегат для Invoke будет вызван немедленно, а для BeginInvoke — положен в очередь окна.
Пример, который по моему, показателен.

С уважением, Gleb.

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

...
GZ>

GZ>Если caller находится в том-же потоке, то делегат для Invoke будет вызван немедленно, а для BeginInvoke — положен в очередь окна.
А как ты думаешь кто возьмет его из очереди и выполнит?
Если это сделает вызывающий поток — то с тем же успехом можно было сделать этот вызов синхронным (только делать его в этом случае нужно было в другом определеннолм месте).

Например.

асинхронно:

делаем что-то 1;
асинхронный вызов (кладем в очередь окна);
делаем что-то долго 2;
достаем из очереди окна и делаем;

тоже самое синхронно с тем же успехом (выполнится еще быстрее)

делаем что-то 1;
делаем что-то долго 2;
синхронный вызов;

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

TK>Hello, "Tom"
>>
>> Затем, что обычно реализуются асинхронные вызовы через выполнение этого
>> самого вызова где то отдельно и это отдельно почти всегда есть поток.

TK>ок. давай по пунктам.

TK>1. Асинхронный ввод/вывод (конкретно ReadFileEx из WinAPI) создает отдельный
TK>поток для выполнения чтения?

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

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

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

Tom>>Хорошо, тогда скажи к чему болл применимо высказывание "...separatly so that...":
Tom>>1. in the same thread
Tom>>2. in the another thread
GZ>Да ни к чему из этого неприменимо. Ясно сказано — раздельно так, чтобы вызывающий мог продолжать выполнять инструкции без ожидания возврата функции. Если вызывающий поток ожидает возврата функции то это можно нельзя считать "раздельно".
Ты определись можно или нельзя.

GZ>А если это не "раздельно" -> то это не асинхронный вызов. В какое время будет работать вызываемая функция — одновременно или после, несказано.
GZ>Плохо с понятиями, давай по коду.\
Да, с понятиями у меня точно плохо, слава богу у нас есть ТК

GZ>Надеюсь ты не будешь возражать что Control.BeginInvoke — асинхронен. Посмотрим на него на рефлектор.
GZ>

GZ>//вызов BeginInvoke приводит к вызову этой функции с параметром synchronous=false
GZ>//вызов Invoke приводит к вызову этой функции с параметром synchronous=false
GZ>private object MarshaledInvoke(Control caller, Delegate method, object[] args, bool synchronous)
GZ>{
GZ>//скинуто как неинтересное
GZ>//..........
GZ>//скинуто как неинтересное
GZ>      bool flag1 = false;
GZ>//проверяем а не находимся ли в том же потоке в случае вызова Invoke
GZ>      if ((SafeNativeMethods.GetWindowThreadProcessId(new HandleRef(this, this.Handle), out num1) == SafeNativeMethods.GetCurrentThreadId()) && synchronous)
GZ>      {
GZ>            flag1 = true;
GZ>      }
GZ>//скинуто как неинтересное
GZ>//..........
GZ>//скинуто как неинтересное

GZ>      if (flag1)
GZ>      {
GZ>//выполняется только если мы уже находимся в потоке и это вызов Invoke
GZ>            this.InvokeMarshaledCallbacks();
GZ>      }
GZ>      else
GZ>      {
GZ>//если это вызов BeginInvoke или если это вызов Invoke и мы находимся в другом потоке  
GZ>            UnsafeNativeMethods.PostMessage(new HandleRef(this, this.Handle), Control.threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
GZ>      }
GZ>//главное отличие BeginInvoke от Invoke - мы здесь не дожидаемся а выходим
GZ>      if (!synchronous)
GZ>      {
GZ>            return entry1;
GZ>      }
GZ>//обеспечение синхронности вызова для Invoke
GZ>      if (!entry1.IsCompleted)
GZ>      {
GZ>            entry1.AsyncWaitHandle.WaitOne();
GZ>      }
GZ>      if (entry1.exception != null)
GZ>      {
GZ>            throw entry1.exception;
GZ>      }
GZ>      return entry1.retVal;
GZ>}
GZ>

GZ>Если caller находится в другом потоке, то вызов Invoke и BeginInvoke — одинаковы. Только для BeginInvoke — важно выйти не узнавая, выполнилась ли эта процедура, или нет.
Код не смотрел, так как декомпиляция MS сборок — незаконна, а я не хочу учить понятия в местах отдалённых от рабочего.

GZ>Если caller находится в том-же потоке, то делегат для Invoke будет вызван немедленно, а для BeginInvoke — положен в очередь окна.
GZ>Пример, который по моему, показателен.
А что он показывает? Как работает стандартный алгоритм SendMessage-а и оконные сообщения? Так это и так все уже лет 10 знают...

Дf и потом ты определись наконец что ты хочешь доказать?

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

Tom>>>Хорошо, тогда скажи к чему болл применимо высказывание "...separatly so that...":
Tom>>>1. in the same thread
Tom>>>2. in the another thread
GZ>>Да ни к чему из этого неприменимо. Ясно сказано — раздельно так, чтобы вызывающий мог продолжать выполнять инструкции без ожидания возврата функции. Если вызывающий поток ожидает возврата функции то это можно нельзя считать "раздельно".
Tom>Ты определись можно или нельзя.
Oops. описка. Ессно нельзя. Доказательство от противного.

GZ>>Если caller находится в другом потоке, то вызов Invoke и BeginInvoke — одинаковы. Только для BeginInvoke — важно выйти не узнавая, выполнилась ли эта процедура, или нет.
Tom>Код не смотрел, так как декомпиляция MS сборок — незаконна, а я не хочу учить понятия в местах отдалённых от рабочего.
Ну уж ляниво по интеру бегать. Подай в суд.

GZ>>Если caller находится в том-же потоке, то делегат для Invoke будет вызван немедленно, а для BeginInvoke — положен в очередь окна.
GZ>>Пример, который по моему, показателен.
Tom>А что он показывает? Как работает стандартный алгоритм SendMessage-а и оконные сообщения? Так это и так все уже лет 10 знают...
Он показывает, что асинхронный делегат в BeginInvoke будет вызываться в том же потоке, и будет вызван не во время работы вызывающей функции а только после. То есть, параллельности здесь никакой. И следовательно, в концепции неважно same это поток, или other. Она небось и не знает что такое поток. Это не все-таки не термин языка, а термин windows.

Tom>Дf и потом ты определись наконец что ты хочешь доказать?
Дf уже и доказывать ничего не буду. Надоело.
MSDN — не указ, код мы не читаем. Рычаги давления кончились, пойду домой и забуду про этот флейм. Благо смысла в нем, не на грош.

С уважением, Gleb.

Hello, "Tom"
>
> ReadFileEx это синхронный вызов, и он сразу возвращает результат. Не
> путать асинхронынй вызов с асинхронным чтением (см выделенное). Вот если
> запустить поток в котором вызвать ReadFileEx это будет асинхронный вызов
> ReadFileEx, опять же не путать с асинхронным чтением.

Молодец, уже лучше Только как-то не аккуратненько... Запуск потока это
запуск потока, вызов ReadFileEx это вызов ReadFileEx (вызываешь ты ее все
равно синхронно). Где асинхронность вызова ReadFileEx-то? На да ладно...

Давай лучше разберем FileStream.BeginRead — где тут потоки и кто их создает?

Здравствуйте, Аноним, Вы писали:

Повторяться не буду. Ответ на твой вопрос уже прозвучал во флейме, и он был однозначный.

С уважением, Gleb.

TK>Давай лучше разберем FileStream.BeginRead — где тут потоки и кто их создает?
Ты эта, перечитай моё сообщение на которое ты ответил (6 твоих постов назад)

А ты говоришь понятия понятия

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

GZ>Здравствуйте, Аноним, Вы писали:

А>>Нарушается мое условие которое я поставил в первом сообщении топика "(Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)".
GZ>Тебе уже указали. В принципе, любая работа ввода-вывода с периферийного устройства. Копирование данных память-устройство происходит не через процессор, а через каналы DMA и не требуют потока. Заниматься такой фигней как ожидание, в это время смысла нет.

DMA это проблемы ОС. А в виндовс ты работашь с некоторым АПИ. И тут или Виндузный OVERLAPPED, или ручная ассинхронность на потоках. Так как FileStream не требует задавать ассинхронность при открытии файла (а OVERLAPPED требует), то скорее всего фрэймворк эмулирует ассинхронность самостоятельно. Ну, и естественно он это делает на потоках из пула, что подтверждается простеньким тестом

Автор: VladD2
Дата: 05.10.05

.

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

M>Хотя тут обсуждался больше BeginRead для FileStream, наиболее наглядная выгода от асинхронности (по сравнению с многопоточностью) появляется в сетевых приложениях.

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

Что касается "BeginRead для FileStream", погляди, плиз вот это

Автор: VladD2
Дата: 05.10.05

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

Здравствуйте, <Аноним>, Вы писали:

А>А уведомление вызывающего потока о завершении работы ввода-вывода создаст и отдаст тоже DMA канал?

В FileStream поток не уведомляется. Там уведомление посылается в другой поток

Автор: VladD2
Дата: 05.10.05

.

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

A>кто-нить может привести код с асинхронной работой FileStream.BeginRead?

Re: Асинхронная операция в рамках одного потока?

Автор: VladD2
Дата: 05.10.05

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

GZ>Асинхронный вызов означает что вызывающий поток не ожидает результат вызова и тогда вызов асинхронен относительно вызывающего потока.

Ага. Вот только ассинхронное опвевещение (колбэк) таки без другого потока не какти.

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

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

DMA и физические девайсы это конечно здорово. Но читается то файл, а не физические кластеры на диске. Там еще нужно сигналы на шину подать и т.п. Когда используется DMA для оповещении о завершении операции используются IRQ, а в них не то что вызвать колбэк нельзя. В них вообще нужно по проворнее двигаться. Файловые же системы это отдельный и не маленький код, так что потоки ОС там по любому присутствуют. Должен же кто-то дать команды на чтение кластеров, преобразовать это все в буфер и установить событие?

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

GZ>>Тебе уже указали. В принципе, любая работа ввода-вывода с периферийного устройства. Копирование данных память-устройство происходит не через процессор, а через каналы DMA и не требуют потока. Заниматься такой фигней как ожидание, в это время смысла нет.

VD>DMA это проблемы ОС. А в виндовс ты работашь с некоторым АПИ. И тут или Виндузный OVERLAPPED, или ручная ассинхронность на потоках. Так как FileStream не требует задавать ассинхронность при открытии файла (а OVERLAPPED требует), то скорее всего фрэймворк эмулирует ассинхронность самостоятельно. Ну, и естественно он это делает на потоках из пула, что подтверждается простеньким тестом

Автор: VladD2
Дата: 05.10.05

.

Глянул, Рефлектором. Там все же OVERLAPPED. Однако не ясно как это прокатывает. Ведь как минимум в 95-ых с этим большие проблемы. Да и пользуются для чтения они все же ReadFile, а не ReadFileEx.

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

GZ>Он показывает, что асинхронный делегат в BeginInvoke будет вызываться в том же потоке, и будет вызван не во время работы вызывающей функции а только после.

Не, ну, это ты уже совсем пургу несешь. Причем тут "асинхронный делегат" и "очереди окна"? Ненадо путать Control.BeginInvoke и Delegate.BeginInvoke. Это разные вещи. Один осуществляет передачу управления в GUI-поток по средстам посылки сообщения через PostMessage, а второй просто вызвает метод в одном из потоков пула.

GZ>MSDN — не указ, код мы не читаем. Рычаги давления кончились, пойду домой и забуду про этот флейм. Благо смысла в нем, не на грош.


Вы ребятки разговариваете о разных вещах, да еще и перепрыгивая на разные уровни абстракции.

Короче в голове каша. Давайте как приведем все в порядк.

Итак, чтение из файла в Виндовс действительно может делаться ассинхронно если исползуется Overlapped I/O. При этом внутри Виндовс параллельность чтения осуществляется довольно сложными механизмами где без рабочих потоков вряд ли можно обойнись. Но думаю Том говорит не об этом. Том говорит о том, что чтобы уведомить приложение о завершении операции как не крути нужно сделать это в другом потоке. Ведь этот поток необязан быть GUI-потоком, и уж темболее не обязан постоянно выбирать очередь приложения чтобы обрабоаться какие-то там сообщения посланные PostMessage-ом. Так что для оповещения поток нужен по любому.

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

Так что все одновременно и правы, и не правы. Смотря как посмотреть.

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

VD>2. Это поток из дотнетного пула, так что скорее всего ассинхронность реализована в данном случае в недрах дотнета.

Поглядел Рефлектором... Чтение делается через Overlapped I/O, но оповещение идет из потока пула. Там вообще все довольно хитро устроено. Без пол литры не разберашся. Оповещение приходит из _IOCompletionCallback.PerformIOCompletionCallback().

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

Хороший ответ!

M>Общая мысль такова. Если вы создаёте свой собственный отдельный поток для операций ввода-вывода, вы неэкономно расходуете ресурсы. Так как всё равно за кулисами при выполнении операций I/O будут задействованы разные системные потоки, создание ещё и своего отдельного неуместно. Лучше "положиться" на существующий механизм, то есть задейстовать именно асинхронные вызовы.

А здесь я бы поспорил. Тут все зависит от задачи. Если чтение файла само по себе производится в контексте некоторой ассинхронной операции, то смысла в ассинхронном чтении все нет. Поток то все равно заводить. Ну, и опять же потом можно взять из пула. Так что тут наверно лучше думать как уобнее, а не как экономнее.

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

А>>>Нарушается мое условие которое я поставил в первом сообщении топика "(Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)".
GZ>>Тебе уже указали. В принципе, любая работа ввода-вывода с периферийного устройства. Копирование данных память-устройство происходит не через процессор, а через каналы DMA и не требуют потока. Заниматься такой фигней как ожидание, в это время смысла нет.

VD>DMA это проблемы ОС. А в виндовс ты работашь с некоторым АПИ. И тут или Виндузный OVERLAPPED, или ручная ассинхронность на потоках. Так как FileStream не требует задавать ассинхронность при открытии файла (а OVERLAPPED требует), то скорее всего фрэймворк эмулирует ассинхронность самостоятельно. Ну, и естественно он это делает на потоках из пула, что подтверждается простеньким тестом

Автор: VladD2
Дата: 05.10.05

.
В данном случае — это был конкретный ответ на конкретный вопрос. В более полном виде написал mihailik. Просто тут более низкий уровень(и мой прошлый опыт).

С уважением, Gleb.

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

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

GZ>>Асинхронный вызов означает что вызывающий поток не ожидает результат вызова и тогда вызов асинхронен относительно вызывающего потока.

VD>Ага. Вот только ассинхронное опвевещение (колбэк) таки без другого потока не какти.
Асинхронный вызов не обязательно должен приводить к асинхронному оповещению.
Что касается асинхронного оповещения, то это можно эмулировать и через какую-либо систему очередей в том же потоке. Ну, например, WM_TIMER. Просто через поток удобнее, хотя иногда обходится дороже.

С уважением, Gleb.

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

VD>Глянул, Рефлектором. Там все же OVERLAPPED. Однако не ясно как это прокатывает. Ведь как минимум в 95-ых с этим большие проблемы. Да и пользуются для чтения они все же ReadFile, а не ReadFileEx.
Дело в том, что ReadFile нормально работает со структурой OVERLAPPED и для синхронного чтения. Там если отсутсвует флаг какой-то при открытии, но OVERLAPPED то идет синхронный вызов но с работой по структуре оверлаp. Сам как-то делал такую штуку для эмуляции асинхронности в Win95. Весьма удобно.

С уважением, Gleb.

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

GZ>Что касается асинхронного оповещения, то это можно эмулировать и через какую-либо систему очередей в том же потоке. Ну, например, WM_TIMER. Просто через поток удобнее, хотя иногда обходится дороже.

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

M>> Лучше "положиться" на существующий механизм, то есть задейстовать именно асинхронные вызовы.

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

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

M>>Хотя тут обсуждался больше BeginRead для FileStream, наиболее наглядная выгода от асинхронности (по сравнению с многопоточностью) появляется в сетевых приложениях.

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

Да, тут я противопоставляю. Я имею в виду, что при использовании класса Thread мы создаём потоки вручную и, казалось бы, можем управлять всем гибче и эффективнее. Но это ложное чувство

А на самом деле штатные асинхронные методы работы значительно эффективнее ручного создания потоков и использования синхронных вызовов внутри этих потоков. Потому что при асинхронных вызовах мы как минимум используем готовые потоки из пула. А как максимум — задействуем механизмы асинхронности ОС и вообще не добавляем новых потоков.



VD>Что касается "BeginRead для FileStream", погляди, плиз вот это

Автор: VladD2
Дата: 05.10.05

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

Я полностью согласен. Код AsyncCallback будет в любом случае выполняться в потоке из дотнетовского ThreadPool.

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

VD>Заблуждаешся. WM_TIMER не работает если нет выборки сообщений, т.е. сервисы, консольные приложения и т.п. Ну, и WM_TIMER обрабатывается только при прокачке сообщений, а оповещения должны и без них работать. Так что кроме отдельного потока тут ничего другого быть не может.
Чего-то я не понял. Мы обсуждаем асинхронные оповещения как функциональность, или те которые должны работать в консольных приложениях? Ведь в этом случае не будет работать на Win16 за неимением потоков. Можно обсудить асинхронность в Java. Там есть такой паттерн future(недавно пробегало). Это еще тот прикол.
Вобщем, какой-то бред пошел по флейму.

С уважением, Gleb.

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

S>Здравствуйте, <Аноним>, Вы писали:
А>>Так вам не кажется, что слово "separately" это латентно "in some other thread"?
S>Нет. Не надо изобретать скрытый смысл там, где его нету. separately ортогонально in some other thread.
S>Например, во время обработки какого-то сообщения я вызываю Invalidate. Как уже сказали, я не дожидаюсь окночания операции перерисовки, то есть вызов — асинхронный.

Из MSDN:

Control.Invalidate Method C#

Invalidates a specific region of the control and causes a paint message to be sent to the control.

Про асинхронность ничего не сказано
Метод отрабатывает АБСОЛЮТНО СИНХРОННО.

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

S>Про асинхронность ничего не сказано
Ничего страшного. Главное — не надо придумывать то, чего там не написано.
S>Метод отрабатывает АБСОЛЮТНО СИНХРОННО.
Щас прям. Читать про Control.Update до просветления.

Executes any pending requests for painting.

There are two ways to repaint a form and its contents:

You can use one of the overloads of the Invalidate method with the Update method.

You can call the Refresh method, which forces the control to redraw itself and all its children. This is equivalent to setting the Invalidate method to true and using it with Update.

The Invalidate method governs what gets painted or repainted. The Update method governs when the painting or repainting occurs. If you use the Invalidate and Update methods together rather than calling Refresh, what gets repainted depends on which overload of Invalidate you use. The Update method just forces the control to be painted immediately, but the Invalidate method governs what gets painted when you call the Update method.

For more information, see the WM_PAINT topic of the "Painting and Drawing" section of the Platform SDK documentation in the MSDN library at http://msdn.microsoft.com/library.

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

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

S>The Invalidate method governs what gets painted or repainted. The Update method governs when the painting or repainting occurs. If you use the Invalidate and Update methods together rather than calling Refresh, what gets repainted depends on which overload of Invalidate you use. The Update method just forces the control to be painted immediately, but the Invalidate method governs what gets painted when you call the Update method.

S>For more information, see the WM_PAINT topic of the "Painting and Drawing" section of the Platform SDK documentation in the MSDN library at http://msdn.microsoft.com/library.
S>[/q]

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

Но используется метод для Асинхронной Операции Перерисовки ( но метод и операция в контексте которой он выполняется — вещи ИМХО разные).

Если бы метод Invalidate был бы асинхронный, то он должен был бы возвращать статус выполнения ( Подробности в WinSock для асинхронных вызовов ).

Я все сказал.

ЗЫ: Понимаю, что Вы имели в виду, но сформулированны Ваши мысли были некорректно, к чему собственно и мои претензии

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

VD>Файловые же системы это отдельный и не маленький код, так что потоки ОС там по любому присутствуют. Должен же кто-то дать команды на чтение кластеров, преобразовать это все в буфер и установить событие?

Хочешь сказать, что этим занимаются потоки из user mode?

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

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

TK>>От себя могу сказать, что вызов делегата через BeginInvoke тоже ничего не
TK>>гарантирует.

VD>Ну, он точно гарантирует запуск в другом потоке.

Ты не прав. Я уже приводил примеры когда вызов делега через BeginInvoke всегда будет осуществляться в том-же потоке — такова реализация.

Здравствуйте, Аноним, Вы писали:

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

TK>>Hello,

>>> TK>О завершении операции сигнализирует объект ядра. Разве сложно MSDN
>>> почитать?
>>> А объект ядра живет отдельно вне потоков? Разве сложно задуматься?

TK>>Мало того, объекты ядра живут вне процессов
А>Процессы тут вообще не причем
А>А поточно любое действие при достаточной его детализации.

Сигнал — это не действие. Это, скорее, состояние.

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

TK>Хочешь сказать, что этим занимаются потоки из user mode?

А что кольцо защиты в котором выполняется поток как-то влияет на рассуждения о его наличии или отсутствии?

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

S>Сам метод Invalidate отрабатывает синхронно, именно это и написано, его задача — пометить то, что должно перерисоваться.
Боюсь, что асинхронных методов мы не увидим.
S>Но используется метод для Асинхронной Операции Перерисовки ( но метод и операция в контексте которой он выполняется — вещи ИМХО разные).

S>Если бы метод Invalidate был бы асинхронный, то он должен был бы возвращать статус выполнения ( Подробности в WinSock для асинхронных вызовов ).
Это почему еще? Кто сказал, что понятие асинхронных вызовов определяется WinSock?
Вызовы методов, конечно же, синхронны. Вообще все. В том числе и Delegate.BeginInvoke.
S>Я все сказал.

S>ЗЫ: Понимаю, что Вы имели в виду, но сформулированны Ваши мысли были некорректно, к чему собственно и мои претензии
Да я вижу. Но не понимаю, что было корректной формулировкой.

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

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

S>Боюсь, что асинхронных методов мы не увидим.

Platform SDK: DLLs, Processes, and Threads

OVERLAPPED
...

Members
Internal
Reserved for operating system use. This member, which specifies a system-dependent status, is valid when the GetOverlappedResult function returns without setting the extended error information to ERROR_IO_PENDING.
.....

GetOverlappedResult возвращает статус выполнения асинхронной операции — это именно то, что я имел в виду.

И еще есть CancelIo, которая может оменить асинхронную операцию.

Подобной функциональности ни метод Invalidate ни Update — не предоставляют, вот именно это я и имел ввиду, я больше склонен рассматривать Invalidate — как отложенную операцию.

S>Это почему еще? Кто сказал, что понятие асинхронных вызовов определяется WinSock?
S>Вызовы методов, конечно же, синхронны. Вообще все. В том числе и Delegate.BeginInvoke.
S>>Я все сказал.

WinSock я привел как пример асинхроных вызывов, корторые возвращают результат выполнения асинхронной операции.

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


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

S>Подобной функциональности ни метод Invalidate ни Update — не предоставляют, вот именно это я и имел ввиду, я больше склонен рассматривать Invalidate — как отложенную операцию.
Ага, то есть теперь у нас есть три определения:
— синхронная операция
— асинхронная операция
— отложенная операция
Отложенная операция есть частный случай асинхронной. Совершенно необязательно иметь возможность подсматривать статус между вызовом асинхронной операции и ее окончанием.
S>WinSock я привел как пример асинхроных вызывов, корторые возвращают результат выполнения асинхронной операции.
И что? Сколько бы примеров не было приведено, это никак не заставит Invalidate выполнять синхронную перерисовку.

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

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

Я удовлетворен
Именно это я и хотел донести, Invalidate это частный случай

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

Формализъм.

С уважением, Gleb.

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

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

GZ>Формализъм.
Каюсь, не без грешка.

Просто дисскусия выродилась ввиду отсутсвия формальных определений ИМХО.

GZ>С уважением, Gleb.
С неменьшим уважением, srggal

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

S>Просто дисскусия выродилась
+1
S>ввиду отсутсвия формальных определений ИМХО.
-1
здесь

Автор: GlebZ
Дата: 04.10.05

Просто некоторые пытались неоднозначно трактовать.

С уважением, Gleb.

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

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

S>>Просто дисскусия выродилась
GZ>+1
S>>ввиду отсутсвия формальных определений ИМХО.
GZ>-1
GZ>здесь

Автор: GlebZ
Дата: 04.10.05

GZ>Просто некоторые пытались неоднозначно трактовать.

GZ>С уважением, Gleb.

Неоднозначная трактовка лпределений говорит об их недостаточной формальности

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

TK>Ты не прав. Я уже приводил примеры когда вызов делега через BeginInvoke всегда будет осуществляться в том-же потоке — такова реализация.

Ссылку можно?

TK>Ты не прав. Я уже приводил примеры когда вызов делега через BeginInvoke всегда будет осуществляться в том-же потоке — такова реализация.

Значит ссылок не будет.

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

GZ>>Асинхронный вызов означает что вызывающий поток не ожидает результат вызова и тогда вызов асинхронен относительно вызывающего потока.

VD>Ага. Вот только ассинхронное опвевещение (колбэк) таки без другого потока не какти.

RPC и APC работают легко без доп. потока, просто нужен некий механизм ожидания в основном потоке, типа очереди сообщений, или "точка сбора" в одном месте, использующем ф-ию из семейства WaitForXXXObjects.

Т.е. в событийной модели асинхронность можно организовать без нескольких потоков. Другой вопрос — в гарантированности обработки событий, т.к. в данном случае налицо "кооперативная" многозадачность.

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

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

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

GZ>>>>С уважением, Gleb.

Tom>>>Можешь ответить на вопрос?

Tom>>>"Так вам не кажется, что слово "separately" это латентно "in some other thread"?"
GZ>>Не вырывай из контекста. "separatly so that". Условие separatly построено строго. И никаких намеков на параллельное выполнение.

Tom>Хорошо, тогда скажи к чему болл применимо высказывание "...separatly so that...":
Tom>1. in the same thread
Tom>2. in the another thread

это более применимо к следующему:
3. at another time

например оверлаппед ввод-вывод работает через прерывания на уровне ядра и через APC на уровне пользователя. И никаких потоков. PostMessage — тоже весьма показательный пример.

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

VD>Значит ссылок не будет.

Воспользуйся поиском. Например, здесь

Автор: bulatich
Дата: 06.06.03

. Если постараться, то можно найти и объяснение.

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

TK>Воспользуйся поиском.

Ну, нормально. Ты значит, и сам не нашел, но поискать посоветовал.

TK> Например, здесь

Автор: bulatich
Дата: 06.06.03

. Если постараться, то можно найти и объяснение.

И как найти это сообщение по словам из твоего сообщения?

ЗЫ

ServicedComponent это всетаки довольно редкое исключение. Про него конечно на всякий случай нужно знать, но в данном случае он непричем.

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

TK>> Например, здесь

Автор: bulatich
Дата: 06.06.03

. Если постараться, то можно найти и объяснение.

VD>И как найти это сообщение по словам из твоего сообщения?

А что, очень сложно? Вся информация в сообщении была ищем.

VD>ServicedComponent это всетаки довольно редкое исключение. Про него конечно на всякий случай нужно знать, но в данном случае он непричем.

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