A simple application is written in CF 2.0. It’s single-threaded as far as I’m concerned.
Two parts of the application are of interest: an event handler that handles ‘Barcode scanned’ event raised by a class that represents PDA’s barcode scanner (provided by manufacturer), and an event handler for Windows.Forms.Timer that runs every 30 seconds.
Recently the application suffered from a bug the only possible reason for which, as I can see, is processing Barcode Scanned event right in the middle of Timer_Tick event. I was absolutely sure that this was not possible and that one of the events would wait in the queue until first one is handled completely. Windows.Forms.Timer page in MSDN also assures that it’s a regular single-threaded timer. Code triggered by Barcode Scanned changes some pieces of the interface, that causes no exceptions, so I’m assuming it’s single-threaded as well. No, we’re not using DoEvents or such.
Can anybody tell me for sure that such reentrancy is not possible and I should look harder for other possible reasons, or vice versa, that they have suffered from the same problem?
The Windows.Forms timer is going to happen on the UI thread via a call to PostMessage. That is a guarantee. How the ‘barcode scanned’ even comes in is completely up to the developer of the library that’s giving you the event. You should certainly not assume that it’s going to run in the same context as your timer unless you specifically force it to (via a call to Control.Invoke). Even with that I don’t believe you can guaranteee a call order.
If you think re-entrancy might be a cause, the solution is relatively simply – use a Monitor in both handlers (the timer proc and the event) and lock on the same object. That will rule out the possibility that it’s a reentrancy issue. If the problem goes away, you know the cause and already have a fix. If the problem persists then you know for certain that it’s not reentrancy and you can focus elsewhere.