Асинхронная операция в рамках одного потока? - Философия программирования

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

Молодец, уже лучше

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

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

Posted via RSDN NNTP Server 1.9

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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