Осигуряване на комуникация чрез асинхронен сериен порт

Ако търсите производителност и асинхронизация на най-доброто ниво, предлагам да разгледате Completion Ports. Това е, което в крайна сметка е отдолу, скрито в ядрото на Windows, и е страхотно. Когато ги използвах, използвах C++, дори открих грешка в ядрото поради него, но бях ограничен до езика.

Видях тази статия в CodeProject, която може да си струва да проучите, за да видите къде може да развие идеята ви и/или да използва кода, който е там.

Естеството на портовете за завършване е да работят върху обратни извиквания. Тоест, като цяло вие "поставяте" заявка в опашката и когато нещо попадне там, заявката се чете и указаното обратно извикване се чете. Всъщност това е опашка, но както казах, на най-ниското (управляемо) ниво (преди да стане почти на метал).

РЕДАКТИРАНЕ: Написах нещо като помощна програма за тестване на FTP сървър/клиент с портове за завършване, така че основният процес е същият - четене и писане на команди в queuable мода. Дано помогне.

РЕДАКТИРАНЕ #2: Добре, ето какво бих направил въз основа на вашите отзиви и коментари. Щях да имам "изходяща опашка", ConcurrentQueue<Message>. Можете да имате отделна нишка за изпращане на съобщения, като премахнете всяко съобщение от опашката. Забележка, ако искате да е малко по-„безопасно“, предлагам да надникнете в съобщението, да го изпратите и след това да го извадите от опашката. Както и да е, класът Message може да бъде вътрешен и да изглежда по следния начин:

private class Message {
    public string Command { get; set; }
    ... additonal properties, like timeouts, etc. ...
}

В класа singleton (ще го нарека CommunicationService), също бих имал ConcurrentBag<Action<Response>>. Тук започва забавлението :o). Когато отделен концерн иска да направи нещо, той се регистрира, например, ако имате TemepratureMeter, бих го накарал да направи нещо подобно:

public class TemperatureMeter {
   private AutoResetEvent _signal = new AutoResetEvent(false);

   public TemperatureMeter {
     CommunicationService.AddHandler(HandlePotentialTemperatureResponse);
   }

   public bool HandlePotentialTemperatureResponse(Response response) {
     // if response is what I'm looking for
     _signal.Set();

     // store the result in a queue or something =)
   }

   public decimal ReadTemperature() {
     CommunicationService.SendCommand(Commands.ReadTemperature);
     _signal.WaitOne(Commands.ReadTemperature.TimeOut); // or smth like this

     return /* dequeued value from the handle potential temperature response */;
   }

}

И сега, във вашата CommunicationService, когато получите отговор, вие просто трябва да a

foreach(var action in this._callbacks) {
   action(rcvResponse);
}

Воаля, разделяне на загрижеността. Отговаря ли по-добре на въпроса ви?

Друга възможна тактика би била да свържете съобщение и обратно извикване, но ако обратното извикване е Func<Response, bool> и нишката на диспечера проверява дали резултатът, върнат от Func, е верен, тогава това обратно извикване се изхвърля.

По-добър избор, ако използвате 4.0, е да използвате BlockingCollection за това, за по-стари версии използвайте комбинация от Queue<T> и AutoResetEvent. Така че ще бъдете уведомени, когато артикулът бъде добавен и в потребителската нишка и след това просто го консумирайте. тук използваме технология за натискане, където при текущото ви внедряване вие ​​използвате технология за анкета „всеки път, когато питате дали има някакви данни“.

Пример: 4.0

//declare the buffer
private BlockingCollection<Data> _buffer = new BlockingCollection<Data>(new ConcurrentQueue<Data>());

//at the producer method "whenever you received an item":
_messageBuffer.Add(new Data());

//at the consumer thread "another thread(s) that is running without to consume the data when it arrived."
foreach (Data data in _buffer.GetConsumingEnumerable())// or "_buffer.Take" it will block here automatically waiting from new items to be added
{
    //handle the data here.
}

Пример: други "по-ниски" версии:

private ConcurrentQueue<Data> _queue = new ConcurrentQueue<Data>();
private AutoResetEvent _queueNotifier = new AutoResetEvent(false);

//at the producer:
_queue.Enqueue(new Data());
_queueNotifier.Set();

//at the consumer:
while (true)//or some condition
{
    _queueNotifier.WaitOne();//here we will block until receive signal notification.
    Data data;
    if (_queue.TryDequeue(out data))
    {
        //handle the data
    }
}