none
Thread.Interrupt parameters RRS feed

  • Question

  • I need to interrupt a thread by using the inetrrupt method.
    The interrupt may be due to different reasons and the code to be executed in the handler depends on the reason.

    Which is the best approach ? A Reason object for which the access is protected by lock ?

    Wouldn't it be convenient if the interrupt caller could pass something which would then be part of the ThreadInterruptedException (e.g. the Data member or similar) which could be used this kind ?

    Thursday, January 12, 2012 10:57 PM

Answers

  • The FileSystemWatcher in .Net is a simple wrapper around the OS's file system watcher. So if a change is made and the FileSystemWatcher doesn't fire an event because it, that means that the OS doesn't know about the change. There is the issue with the buffer being full and events being dropped, but that requires a lot of events. Given that you're currently polling for additions, you probably wouldn't ever run into that situation.

    • Marked as answer by Paul Zhou Monday, January 23, 2012 8:25 AM
    Sunday, January 15, 2012 10:31 PM

All replies

  • Thread.Interrupt isn't for passing data between threads, or for assigning work to different threads.
    Friday, January 13, 2012 12:45 AM
  • I agree if a reason for interrupt should be regarded as "data".
    I guess (not much experience though) that many exception handlers need to "look around" to find the reason for interrupt anyway, so why not give it to him in the first place.
    Another academic thought is regarding the Exception instance which is passed to the handler, as far as I can see, this is of no use and could be set by the caller of the interrupt, e.g. theThread.Interrupt(new ThreadInterruptedException() { Reason = theReason}) or similar (yes, I know that Reason is not a property, but it could be (should be ?))

    Friday, January 13, 2012 6:50 AM
  • From what I can tell Thread.Interrupt is something akin to Thread.Abort, just not as harsh. My only guess as to why it would be useful would be if a program had to use a third party libarary which deadlocked, and the program would need a way to un-deadlock itself.

    I don't think that adding a reason would be a good idea. It would then be tempting for poor programers to use it as a way to create a poor message passing system.

    Saturday, January 14, 2012 8:54 PM
  • After a second (third) thought, I suppose you are correct, I think I was on my way to misuse this.

    In my case I have a thread which is normally sleeping (Thread.Sleep(napTime)) and when it does not sleep, it looks at the file system to see if some file has been added for processing by the thread and then possibly send out to a modem by AT commands.

    Occasionally the modem sends back something which is not a response to a command from the thread, these should be handled, preferably by the same thread as is normally waiting (because it should lead to a new set of commands going back to the modem).
    This is why I thought Interrupt was a good idea, I could do without any reason, because for now the mentioned above is the single possible reason, but future...

    So I think I will change and probably do it by firing up another thread instead (System.Threading.Tasks.Task I guess) from threadpool this time and make the access code for writing to the modem threadsafe by lock, do you think that is a better approach ?

    Sunday, January 15, 2012 4:37 PM
  • Hopefully you can use a FileSystemWatcher to watch the directory get alerted to changes, instead of polling.

    While I don't exactly how you want the modem code to work, if I were in the situation I would offload the handling of the data to a different thread in the ThreadPool.

    If the modem resource can't be written to by more than one thread at a time, creating a lock around the resource sounds like a good idea. I've never had to deal with a network card that behaves like that, but you might be writing something that's lowerlevel and not using classes from the System.Net namespace.

    Sunday, January 15, 2012 9:33 PM
  • Thanks jader3d,
    No System.Net here, it is System.IO.Ports.SerialPort (RS232 comm port), which is not reliable by itself (http://zachsaw.blogspot.com/2010_07_01_archive.html makes it a lot better).

    I have read some articles claiming that FilseSystemWatcher is not 100% reliable, therefore I poll files existencies.
    My application is a critical alarm dispatcher and must be 100% relible, of course I could "partially trust" FileSystemWatcher and poll once in a while to be sure (timing is not that critical).

    Sunday, January 15, 2012 10:05 PM
  • The FileSystemWatcher in .Net is a simple wrapper around the OS's file system watcher. So if a change is made and the FileSystemWatcher doesn't fire an event because it, that means that the OS doesn't know about the change. There is the issue with the buffer being full and events being dropped, but that requires a lot of events. Given that you're currently polling for additions, you probably wouldn't ever run into that situation.

    • Marked as answer by Paul Zhou Monday, January 23, 2012 8:25 AM
    Sunday, January 15, 2012 10:31 PM