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

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

TK>Думаю, что более правильно будет "если рассматривать CLR как черный ящик по
TK>отношению к программисту то точка зрения что будут создаватся доп. потоки
TK>имеет право на существование". Что касается CLR то, OC для нее черным ящиком
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.
Это не есть верно в случае 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 потока.

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello,

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

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