none
How to force section of code not to interrupt while being ran on dedicated thread? RRS feed

  • Question

  • I was wondering if it's possible to set a region in the code that once it starts executing, the thread will not be interrupted? I'm working on a program that talks to multiple devices via serial ports and uses dedicated thread for each device to perform data collection and such. Once in a while I have to send some data to that device and I'd like to make sure that once I run a region of code where it's sending data I want to be sure that this thread will not be interrupted so that communications do not time out.

    • Edited by Dom581 Saturday, July 5, 2008 9:33 PM Subject
    Saturday, July 5, 2008 9:32 PM

Answers

  • It's not quite as bad as it sounds.  While you can indeed do nothing to prevent a thread from getting interrupted, Windows gives a thread that was waiting on an I/O completion event a temporary priority boost.  That ensures your thread starts running quickly and usually gives you plenty of time to respond to the I/O event.  To make sure you get that priority boost, make sure you don't poll.  Use the DataReceived event or block on a Read() method call.

    This will work just fine 99.99% of the time.  What Windows won't guarantee is a reasonable upper limit to the worst-case response time.  To cover that, you'll have to ensure you have a protocol that is resilient to timeouts.  Such a protocol is required regardless of Windows imperfect realtime behavior, serial ports are far to unreliable to trust them to always get the message across without problems.  Be sure to test your protocol for such mishaps.  It is next to impossible to get Windows to give you its worst-case behavior on demand.  Simulate the mishaps by programming random Sleep() calls in your test setup.  Getting the checksum wrong or intentionally dropping a byte while testing is a good idea for the same reason.

    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Monday, July 14, 2008 2:28 AM
    Sunday, July 6, 2008 4:29 PM
    Moderator

All replies

  • There is no way (in windows) to prevent the OS to preempt your thraeds.
    What you can do is to synchronize your threads so that they will not interrupt your IO, and change the thread priority to HIGH (or real-time).
    Windows is not a deterministic machine and as such does not ensure anything.

    navo
    Sunday, July 6, 2008 1:52 PM
  • How could I synchronize it? There's no data sharing between each of the threads so if I use a lock or another way, I don't think it would make a difference because that object is only accessed by one thread anyways.
    Sunday, July 6, 2008 4:16 PM
  • It's not quite as bad as it sounds.  While you can indeed do nothing to prevent a thread from getting interrupted, Windows gives a thread that was waiting on an I/O completion event a temporary priority boost.  That ensures your thread starts running quickly and usually gives you plenty of time to respond to the I/O event.  To make sure you get that priority boost, make sure you don't poll.  Use the DataReceived event or block on a Read() method call.

    This will work just fine 99.99% of the time.  What Windows won't guarantee is a reasonable upper limit to the worst-case response time.  To cover that, you'll have to ensure you have a protocol that is resilient to timeouts.  Such a protocol is required regardless of Windows imperfect realtime behavior, serial ports are far to unreliable to trust them to always get the message across without problems.  Be sure to test your protocol for such mishaps.  It is next to impossible to get Windows to give you its worst-case behavior on demand.  Simulate the mishaps by programming random Sleep() calls in your test setup.  Getting the checksum wrong or intentionally dropping a byte while testing is a good idea for the same reason.

    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Monday, July 14, 2008 2:28 AM
    Sunday, July 6, 2008 4:29 PM
    Moderator