Interrupts... Thread Safe?

NETMF & Gadgeteer
1

Morning folks. Last night I had my robot responding to an interrupt whenever the encoder pulsed which would simply (leftEncoder++;) increment a counter. I would have the program send send the counter (leftEncoder.toString():wink: out the XBEE. All seemed fineā€¦ rotate the wheel and see the count on the XBEE comms. However after a few minutes, the Fez seemed to lock up.

The only thing I can think of at this time is perhaps this is caused by reading a value that is being modified by another thread. Am I way off base here or not?

For reference, I donā€™t believe its the XBEE as I have sent gps data out it for hours with no problem.

2

We need sample code as somethingā€™s amiss!! Some of us here may see a small hicup in your code and put you straight.

Cheers Ian

3

Increment is both a read and a write which is *not thread safe. At least in .Net. In netmf, I assume same, but not much writen on the memory model.

The ā€œincrementā€ is not atomic. A write to an int is atomic - which means different threads will not see a ā€œtornā€ read, but the read-write operation in total is not atomic. To be fully atomic, use a lock or Interlocked.Increment. Your interupt is on another thread (set a Debugger.Break() in your callback to see all the threads).

4

Thanks! It seems Gus has better things for me to do right now so my focus has changed some. :slight_smile:

5

Doesnā€™t really answer the original question but the Interlocked.Increment and Interlocked.Decrement static methods in System.Theading should be thread safe and (supposedly) fast.