Существует ли пример, когда асинхронная операция выполняется в вызывающем потоке, причем оправданно? (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)
Собственно смущает статус MVP человека, написавшего это.
04.10.05 22:19: Перенесено модератором из '.NET' — TK
Здравствуйте, <Аноним>, Вы писали:
А>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем." А>и частично А>http://rsdn.ru/Forum/?mid=1208906
Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода метода при асинхронном вызове происходит всегда в другом потоке — не в том, из которого вызов был произведён. Другое дело, что поток для асинхронного вызова берётся из пула потоков — возможно, поэтому на деле используется пара потоков для большого количества асинхронных вызовов.
Асинхронная операция в рамках одного потока?
От:
Аноним
Дата:
04.10.05 12:05
Оценка:
Пример: асинхронная работа с СОМ портом, пока он там себе читает возможно нет необходимости все тормозить и ждать результата.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, <Аноним>, Вы писали:
А>>Цитата — "Многопоточность — это много потоков. А асинхронность — это как правило один поток, который грамотно распоряжается рабочим временем." А>>и частично А>>http://rsdn.ru/Forum/?mid=1208906
O>Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода метода при асинхронном вызове происходит всегда в другом потоке — не в том, из которого вызов был произведён. Другое дело, что поток для асинхронного вызова берётся из пула потоков — возможно, поэтому на деле используется пара потоков для большого количества асинхронных вызовов.
Так и есть, поток для исполнения кода вызываемого асинхронно берется из пула, НО это уже как минимум 2 потока — вызывающий и взятый из пула.
А>Существует ли пример, когда асинхронная операция выполняется в вызывающем потоке, причем оправданно? (Оправданно — в смысле что тоже самое не может работать также эффективно синхронно)
У меня Beginread на который ссылался Михайлик, вообще не имеет ничего общего с асинхронностью. Все происходит тупо в вызывающем потоке, т.е. как обычная синхронная операция. Так что к вопросу автора я добавлю свой — кто-нить может привести код с асинхронной работой FileStream.BeginRead?
Re: Асинхронная операция в рамках одного потока?
От:
Аноним
Дата:
04.10.05 12:17
Оценка:
Здравствуйте, AndroidLV, Вы писали:
ALV>Пример: асинхронная работа с СОМ портом, пока он там себе читает возможно нет необходимости все тормозить и ждать результата.
И что? Чтение данных и код после вызова асинхронного чтнеия данных будут исполняться в одном потоке?
Re[2]: Асинхронная операция в рамках одного потока?
Hello, "Oyster" > > Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода > метода при асинхронном вызове происходит всегда в другом потоке — не в > том, из которого вызов был произведён.
Все зависит от реализации. Есть случаи когда это не так.
> Другое дело, что поток для асинхронного вызова берётся из пула потоков — > возможно, поэтому на деле используется пара потоков для большого > количества асинхронных вызовов.
Не надо путать асинхронный вызов чего либо (например делегата) и асинхронный
ввод/вывод. Например, асинхронное чтение файла, создания дополнительного
потока не требует. Стоит почитать MSDN по словам overlapped I/O
Posted via RSDN NNTP Server 1.9
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[2]: Асинхронная операция в рамках одного потока?
Здравствуйте, TK, Вы писали:
TK>Не надо путать асинхронный вызов чего либо (например делегата) и асинхронный TK>ввод/вывод. Например, асинхронное чтение файла, создания дополнительного TK>потока не требует. Стоит почитать MSDN по словам overlapped I/O
[самокритика]
"Иногда лучше жевать, чем говорить"...
[/самокритика]
Re[3]: Асинхронная операция в рамках одного потока?
Hello,
> O>Я могу ошибаться (гуру, поправьте), но вроде как в .NET выполнение кода > метода при асинхронном вызове происходит всегда в другом потоке — не в > том, из которого вызов был произведён. Другое дело, что поток для > асинхронного вызова берётся из пула потоков — возможно, поэтому на деле > используется пара потоков для большого количества асинхронных вызовов. > Так и есть, поток для исполнения кода вызываемого асинхронно берется из > пула, НО это уже как минимум 2 потока — вызывающий и взятый из пула.
Ничего там из пула не берется.
Posted via RSDN NNTP Server 1.9
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[3]: Асинхронная операция в рамках одного потока?
От:
Аноним
Дата:
04.10.05 12:32
Оценка:
Здравствуйте, TK, Вы писали:
TK>Hello, >> И что? Чтение данных и код после вызова асинхронного чтнеия данных будут >> исполняться в одном потоке?
TK>Нет. Заполнение переданного буфера и уведомление о завершении возмет на себя TK>операционная система.
А для этого она не создаст новый поток?
Re[2]: Асинхронная операция в рамках одного потока?
Hello, "Andrbig" > > У меня Beginread на который ссылался Михайлик, вообще не имеет ничего > общего с асинхронностью. Все происходит тупо в вызывающем потоке, т.е. > как обычная синхронная операция. Так что к вопросу автора я добавлю свой — > кто-нить может привести код с асинхронной работой > FileStream.BeginRead?
BeginRead/BeginWrite мегабайта данных на дискетку.
Posted via RSDN NNTP Server 1.9
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[4]: Асинхронная операция в рамках одного потока?
От:
Аноним
Дата:
04.10.05 12:37
Оценка:
Здравствуйте, TK, Вы писали:
>> Так и есть, поток для исполнения кода вызываемого асинхронно берется из >> пула, НО это уже как минимум 2 потока — вызывающий и взятый из пула.
TK>Ничего там из пула не берется.
Hello, > > TK>Нет. Заполнение переданного буфера и уведомление о завершении возмет на > себя > TK>операционная система. > А для этого она не создаст новый поток?
А зачем ей это?
Posted via RSDN NNTP Server 1.9
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[3]: Асинхронная операция в рамках одного потока?
Здравствуйте, 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.
Re[5]: Асинхронная операция в рамках одного потока?
От:
Аноним
Дата:
04.10.05 12:41
Оценка:
Здравствуйте, TK, Вы писали:
TK>Hello, >> >> TK>Нет. Заполнение переданного буфера и уведомление о завершении возмет на >> себя >> TK>операционная система. >> А для этого она не создаст новый поток?
TK>А зачем ей это?
Ну если рассматривать ОС как черный ящик по отношению к CLR то Ваша точка зрения имеет право на существование.
Re[5]: Асинхронная операция в рамках одного потока?
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%
слечаев...
Posted via RSDN NNTP Server 1.9
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[6]: Асинхронная операция в рамках одного потока?
Hello, > > TK>А зачем ей это? > Ну если рассматривать ОС как черный ящик по отношению к CLR то Ваша точка > зрения имеет право на существование.
Думаю, что более правильно будет "если рассматривать CLR как черный ящик по
отношению к программисту то точка зрения что будут создаватся доп. потоки
имеет право на существование". Что касается CLR то, OC для нее черным ящиком
не является и это активно используется.
Posted via RSDN NNTP Server 1.9
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[6]: Асинхронная операция в рамках одного потока?
От:
Аноним
Дата:
04.10.05 12:47
Оценка:
Здравствуйте, 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% и практически для каждого случая есть причина.
В данном случае mihailik прав. Единственное с чем могу не согласиться, это "как правило". Асинхронность и многопотость это разные термины. Асинхронность значит что вызывающая последовательность выполнения не будет ожидать окончания выполнения вызова. Потоки это лишь один из способов выполнения данного требования. Это может быть создание нового потока(или если вам угодно, использование потока из пула), использования уже существующего, или использование текущего. Например, операция Invalidate(перерисовка контрола или формы) операция асинхронная. И если вызывающий поток главный для программы, то это выливается в постановку перерисовки в очередь(стандартная очередь сообщений Win32) в текущем потоке. Если вызывающий поток не главный для программы, то он должен использовать BeginInvoke, который поставит в команду в очередь главного окна. То есть способов использования асинхронности очень много, и они не обязательно должны иметь дополнительный поток.
Все происходит тупо в вызывающем потоке, т.е. как обычная синхронная операция. Так что к вопросу автора я добавлю свой — кто-нить может привести код с асинхронной работой FileStream.BeginRead?
Хотя, если это слишком 
