I am glad it has improved. And yes, made a note on improving the examples in this respect.

There are MANY ways how to hand over a piece of work from one thread to another. QueueUserWorkItem is one of them, it is suitable in some cases, but not all. If it's not good for you, look for something better. You can use e.g. the ConcurrentQueue class ( msdn.microsoft.com/en-us/library/dd267265(v=vs.110).aspx ).

On the same EasyAUClient, you will not receive a new MonitoredItemChanged event until you finished handling the previous one.

But be aware that with QueueUserWorkItem , even with knowing the above statement, on itself won't guarantee the same order of execution. You would have to wait for completion of the work inside the event handler, in order to get a guaranteed order. That's why maybe an approach like with ConcurrentQueue might be better.

If the use of two EasyUAClient objects was meant to address the same issue (calling OPC operation from inside an event handler/callback), then it is not a (full) solution (in addition, with Isolated=true, it causes multiple connections be created).

So I'd suggest to first implement the ThreadPool.QueueUserWorkItem .

Best regards

Yes.

Note that you have not described your issues therefore it' possible that they have other cause. But calling EasyXXClient methods form inside the event/callback handler should be avoided anyway, that's right.