M>> Лучше "положиться" на существующий механизм, то есть задейстовать именно асинхронные вызовы.
VD>А здесь я бы поспорил. Тут все зависит от задачи. Если чтение файла само по себе производится в контексте некоторой ассинхронной операции, то смысла в ассинхронном чтении все нет.
Да, согласен.
Раз уж локальные сетевые операции выполняются "мгновенно" по сравнению с сетевыми, то такой задержкой можно пренебречь.
Re[2]: Асинхронная операция в рамках одного потока?
M>>Хотя тут обсуждался больше BeginRead для FileStream, наиболее наглядная выгода от асинхронности (по сравнению с многопоточностью) появляется в сетевых приложениях.
VD>Ты бы пояснил, что ты вкладывашь в поняте "ассинхронность", а что в "многопоточность". А то из твоих слов я лично могу сделать вывод, что под многопоточностью ты не понимашь ассинхронность. Ведь ты как бы противопоставляшь эти вещи.
Да, тут я противопоставляю. Я имею в виду, что при использовании класса Thread мы создаём потоки вручную и, казалось бы, можем управлять всем гибче и эффективнее. Но это ложное чувство
А на самом деле штатные асинхронные методы работы значительно эффективнее ручного создания потоков и использования синхронных вызовов внутри этих потоков. Потому что при асинхронных вызовах мы как минимум используем готовые потоки из пула. А как максимум — задействуем механизмы асинхронности ОС и вообще не добавляем новых потоков.
VD>Что касается "BeginRead для FileStream", погляди, плиз вот это
Здравствуйте, VladD2, Вы писали:
VD>Заблуждаешся. WM_TIMER не работает если нет выборки сообщений, т.е. сервисы, консольные приложения и т.п. Ну, и WM_TIMER обрабатывается только при прокачке сообщений, а оповещения должны и без них работать. Так что кроме отдельного потока тут ничего другого быть не может.
Чего-то я не понял. Мы обсуждаем асинхронные оповещения как функциональность, или те которые должны работать в консольных приложениях? Ведь в этом случае не будет работать на Win16 за неимением потоков. Можно обсудить асинхронность в Java. Там есть такой паттерн future(недавно пробегало). Это еще тот прикол.
Вобщем, какой-то бред пошел по флейму.
С уважением, Gleb.
Re[8]: Асинхронная операция в рамках одного потока?
Здравствуйте, <Аноним>, Вы писали: А>Так вам не кажется, что слово "separately" это латентно "in some other thread"?
Нет. Не надо изобретать скрытый смысл там, где его нету. separately ортогонально in some other thread.
Например, во время обработки какого-то сообщения я вызываю Invalidate. Как уже сказали, я не дожидаюсь окночания операции перерисовки, то есть вызов — асинхронный.
Пример 2: делаю PostThreadMessage в другой поток и иду дальше. Здесь асинхронный вызов обслуживается другим потоком.
Пример 3: Я делаю SendMessage в окно другого потока. Работу выполняет совершенно другой поток, но вызов — синхронный! Потому, что я дожидаюсь окончания обработки.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Асинхронная операция в рамках одного потока?
Здравствуйте, 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.
Про асинхронность ничего не сказано
Метод отрабатывает АБСОЛЮТНО СИНХРОННО.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[10]: Асинхронная операция в рамках одного потока?
Здравствуйте, 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.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Асинхронная операция в рамках одного потока?
Здравствуйте, 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 для асинхронных вызовов ).
Я все сказал.
ЗЫ: Понимаю, что Вы имели в виду, но сформулированны Ваши мысли были некорректно, к чему собственно и мои претензии
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[8]: Асинхронная операция в рамках одного потока?
Здравствуйте, VladD2, Вы писали:
VD>Файловые же системы это отдельный и не маленький код, так что потоки ОС там по любому присутствуют. Должен же кто-то дать команды на чтение кластеров, преобразовать это все в буфер и установить событие?
Хочешь сказать, что этим занимаются потоки из user mode?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[8]: Асинхронная операция в рамках одного потока?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, TK, Вы писали:
TK>>От себя могу сказать, что вызов делегата через BeginInvoke тоже ничего не TK>>гарантирует.
VD>Ну, он точно гарантирует запуск в другом потоке.
Ты не прав. Я уже приводил примеры когда вызов делега через BeginInvoke всегда будет осуществляться в том-же потоке — такова реализация.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[15]: Асинхронная операция в рамках одного потока?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, TK, Вы писали:
TK>>Hello,
>>> TK>О завершении операции сигнализирует объект ядра. Разве сложно MSDN >>> почитать? >>> А объект ядра живет отдельно вне потоков? Разве сложно задуматься?
TK>>Мало того, объекты ядра живут вне процессов А>Процессы тут вообще не причем А>А поточно любое действие при достаточной его детализации.
Сигнал — это не действие. Это, скорее, состояние.
Re[9]: Асинхронная операция в рамках одного потока?
Здравствуйте, srggal, Вы писали:
S>Сам метод Invalidate отрабатывает синхронно, именно это и написано, его задача — пометить то, что должно перерисоваться.
Боюсь, что асинхронных методов мы не увидим. S>Но используется метод для Асинхронной Операции Перерисовки ( но метод и операция в контексте которой он выполняется — вещи ИМХО разные).
S>Если бы метод Invalidate был бы асинхронный, то он должен был бы возвращать статус выполнения ( Подробности в WinSock для асинхронных вызовов ).
Это почему еще? Кто сказал, что понятие асинхронных вызовов определяется WinSock? Вызовы методов, конечно же, синхронны. Вообще все. В том числе и Delegate.BeginInvoke. S>Я все сказал.
S>ЗЫ: Понимаю, что Вы имели в виду, но сформулированны Ваши мысли были некорректно, к чему собственно и мои претензии
Да я вижу. Но не понимаю, что было корректной формулировкой.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Асинхронная операция в рамках одного потока?
Здравствуйте, 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 я привел как пример асинхроных вызывов, корторые возвращают результат выполнения асинхронной операции.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[14]: Асинхронная операция в рамках одного потока?
S>GetOverlappedResult возвращает статус выполнения асинхронной операции — это именно то, что я имел в виду. S>И еще есть CancelIo, которая может оменить асинхронную операцию.
Это я понимаю. Я не понимаю только, какое отношение GetOverlappedResult имеет к общему случаю асинхронного вызова.
S>Подобной функциональности ни метод Invalidate ни Update — не предоставляют, вот именно это я и имел ввиду, я больше склонен рассматривать Invalidate — как отложенную операцию.
Ага, то есть теперь у нас есть три определения:
— синхронная операция
— асинхронная операция
— отложенная операция
Отложенная операция есть частный случай асинхронной. Совершенно необязательно иметь возможность подсматривать статус между вызовом асинхронной операции и ее окончанием. S>WinSock я привел как пример асинхроных вызывов, корторые возвращают результат выполнения асинхронной операции.
И что? Сколько бы примеров не было приведено, это никак не заставит Invalidate выполнять синхронную перерисовку.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Асинхронная операция в рамках одного потока?
Здравствуйте, Sinclair, Вы писали:
S>Ага, то есть теперь у нас есть три определения: S>- синхронная операция S>- асинхронная операция S>- отложенная операция S>Отложенная операция есть частный случай асинхронной. Совершенно необязательно иметь возможность подсматривать статус между вызовом асинхронной операции и ее окончанием.
Я удовлетворен
Именно это я и хотел донести, Invalidate это частный случай
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[10]: Асинхронная операция в рамках одного потока?
Здравствуйте, TK, Вы писали:
TK>Ты не прав. Я уже приводил примеры когда вызов делега через BeginInvoke всегда будет осуществляться в том-же потоке — такова реализация.
Ссылку можно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ведь в этом случае не будет работать на Win16 за неимением потоков. 
Можно обсудить асинхронность в Java. Там есть такой паттерн future(недавно пробегало). Это еще тот прикол. 
