Hi Christof

>>I am need of limiting access to some methods in a class to a single case.
>
>Wouldn't lock work?
>

>class sample
>{
>  Object myLock = new Object();
>  public void DoSomething()
>  {
>    lock(myLock)
>    {
>       // do something here
>    }
>  }
>}
>

Could I do this with it?

My primary application calls these two commands in order
rfid.CommandProcessor.CreateAttributeCommand("FieldStrength", "50");
rfid.CommandProcessor.CreateAttributeCommand("ANTS", "2");

The CommandProcessor class (methods) formats the command and sends them onto the com port. I do not want the command processor to process the second command until it receives the response from the first. The command processor receives the response via an event that fires and has a handler method in the command processor.

responseMonitor.RfidResponse += new RfidResponseDelegate(responseMonitor_RfidResponseHandler);

In this case the CreateAttributeCommand() would have to create a lock
The responseHandler method would have to unlock it. Or unlock via a timeout.

This doesn't seem like the best idea to place a lock in a method that doesn't also unlock it. Essentially, I need to queue the commands up in the command processor itself so it receives the responses in the same order. I also do not want to block the main thread while the command processor waits for its command/ response stuff to go on.

Using Queue was mentioned and I am looking into it. Also there is:
Mutex, Monitor, Interlock, and Semaphore. I am only familiar (somewhat) with Mutex.

I may be able to stack them on a queue, but then I would have to also monitor the queue constantly in order to know there is something for sending. Unfortunately this seems like unnecessary overhead since commands are not sent all that often within the app. It is just at times when they are; they are in multiples.

Thanks
Tim