Help routing hardware response to correct method call

[Dave]

I have a piece of hardware connected via serial port. I need to send a
variety of commands to the box and route the responses back from the
receive thread to the correct method call.

So e.g. I have a method call something like:

SomeCommand(inParam1, inParam2, outParam1, outParam2)
{
Command cmd = new Command( inParam1, inParam2);
HwCommLine.Send( cmd);
// something happens
Response resp = new Response( outputFromBox );
outParam1 = resp.outValue1;
outParam2 = resp.outValue2;
}

I'm not sure how best to design the "something happens" step to get the
response (outputFromBox) from the receive thread back to the method.

It's ok for the method to block/wait for the response to be available
but there may be many requests being processed at any given time.

Any help/suggestions would be appreciated.

Thanks
Dave

[Nicholas Paldino [.NET/C# MVP]]

Dave,

It sounds like you can have multiple commands and responses going over
the line at the same time. In order to do this, you will have to have a
separate thread which handles the receiving of the responses from the serial
port (it would try to constantly read from the port).

When you send the command, you would have to create a unique identifier
that relates to the command (you could use the thread id that the call is
being made on, since you said you can block the thread while waiting for the
response, but if you made this an async operation, you have to use another
id which is unique). You would then create a ManualResetEvent which you
store in a hashtable, keyed on that id.

You send your message, then have the calling thread wait on that
ManualResetEvent.

In your thread that processes responses, when you get the response that
corresponds to the request that was sent, you take the ManualResetEvent from
the hashtable and then set it, which will release the thread that called
WaitOne. Of course, right before calling this, you would place the details
of the response in a queue somewhere that can be accessed by the thread that
made the request.

While this will work, it won't scale well, and if you have a huge number
of responses, you might want to consider using the thread pool to break up
the code so that the request and the handling of the response are performed
on threads in the thread pool (instead of making threads wait).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Dave" <pi******@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

I have a piece of hardware connected via serial port. I need to send a
variety of commands to the box and route the responses back from the
receive thread to the correct method call.

So e.g. I have a method call something like:

SomeCommand(inParam1, inParam2, outParam1, outParam2)
{
Command cmd = new Command( inParam1, inParam2);
HwCommLine.Send( cmd);
// something happens
Response resp = new Response( outputFromBox );
outParam1 = resp.outValue1;
outParam2 = resp.outValue2;
}

I'm not sure how best to design the "something happens" step to get the
response (outputFromBox) from the receive thread back to the method.

It's ok for the method to block/wait for the response to be available
but there may be many requests being processed at any given time.

Any help/suggestions would be appreciated.

Thanks
Dave

[Dave]

Thanks Nicholas, you pretty much nailed the approach I was intending to
take. I don't want to end up with scaling issues but it isn't obvious
to me how the MSDN example of Thread Pooling works here.

To expand on my original post, this app will be a class derived from
MarshallByRef and hosted in a Windows service with methods accessed
over a tcp channel. So a client makes a method call that gets remoted
to the service. Going back to my original example (and leaving out a
few details) then:

SomeCommand(inParam1, inParam2, outParam1, outParam2)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(SomeCommandProc));
}

void SomeCommandProc(Object stateInfo)
{
Command cmd = new Command( inParam1, inParam2);
HwCommLine.Send( cmd);
// something happens
Response resp = new Response( outputFromBox );
outParam1 = resp.outValue1;
outParam2 = resp.outValue2;
}

I'm obviously missing something here because now I don't see how I can
get my output values back to the client. Should my client be providing
a callback delegate so the service can return the results from the
serial port receive thread?

Thanks
Dave

[Dave]

Thanks Nicholas, you pretty much nailed the approach I was intending to
take. I don't want to end up with scaling issues but it isn't obvious
to me how the MSDN example of Thread Pooling works here.

To expand on my original post, this app will be a class derived from
MarshallByRef and hosted in a Windows service with methods accessed
over a tcp channel. So a client makes a method call that gets remoted
to the service. Going back to my original example (and leaving out a
few details) then:

SomeCommand(inParam1, inParam2, outParam1, outParam2)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(SomeCommandProc));
}

void SomeCommandProc(Object stateInfo)
{
Command cmd = new Command( inParam1, inParam2);
HwCommLine.Send( cmd);
// something happens
Response resp = new Response( outputFromBox );
outParam1 = resp.outValue1;
outParam2 = resp.outValue2;
}

I'm obviously missing something here because now I don't see how I can
get my output values back to the client. Should my client be providing
a callback delegate so the service can return the results from the
serial port receive thread?

Thanks
Dave