0

I am writing a program in C# which is interfacing with a small display unit that does a whole bunch of stuff that's not relevant to this problem.

The problem I have is detailed as follows: When the user selects a button which will attempt to SAVE some settings to the device, it uses an acknowledgement protocol to be sure that the settings went through (Meaning -- It sends settings then waits for acknowledgement packet from the device.)

What I do is I generate a thread in my main application which is going to be the "parent" thread of the threads I am about to generate which will attempt to save to the device. Currently, it works in the following manner:

  • Generate Thread 1 -> Try to save.

  • If timed out, Interrupt Thread 1 (to release the data lock of the device) via Thread.Interrupt() <----- this is the problem. This doesn't work. It bolds the lock until the device is shut off or unplugged then it errors out. (Then it would gen a new thread, which happens now but it never works because the first thread still locking out the data).

  • If it didn't time out, the callback for thread 1 lets the parent thread know not to generate any more threads.

  • Finally, if none of the threads succeeded then the overall attempt failed.

I have also tried doing this with just a single thread being generated and shut down, which also exhibits the same behavior where when waiting for an acknowledgement from the device it hangs permanently until the device is powered off or unplugged.

There is no way to encapsulate that waiting for the device to send an ack with a boolean that could be set to stop the thread because it never leaves the waiting call. This is embedded software so I cannot modify the waiting function. I can only modify the C# interface to the embedded software.

Clifford
  • 88,407
  • 13
  • 85
  • 165
B_Moore
  • 41
  • 1
  • 4
  • What version of the .NET Framework are you using? – Chris Kerekes Jun 15 '12 at 18:08
  • I am not entirely clear about the last point. A function is called to wait for the ACK, but that function exists and runs on the host not the embedded system, so why can it not be modified? Is it rather that it is a closed-source driver? You also have to wonder why the ACK was never received? – Clifford Jun 16 '12 at 07:19

2 Answers2

2

You seem to be saying that your Thread 1 waits forever for the ACK. And another thread detects the timeout condition and tries to interrupt Thread 1. I suggest that Thread 1 should not wait forever but should timeout itself while waiting for the ACK. Then Thread 1 can either retry or exit with an error and there is no need for an interrupt from another thread.

kkrambo
  • 6,643
  • 1
  • 17
  • 30
  • I'm not sure what you mean. A thread wont time itself out if its busy waiting for a function call its running to finish. It's occupied. It has to be interrupted outside of itself, since it is occupied. – B_Moore Jun 15 '12 at 18:38
  • I think @kkrambo is suggesting that you modify thread 1 so that it's aware of a timeout condition. This may be by doing something like polling for a result. It's a bit hard to make specific suggestions without seeing more details about how your thread is locking. – Chris Kerekes Jun 15 '12 at 19:48
  • The function that your thread has called should not run forever. It should timeout and return an error. I'm imagining that you're calling a Read() function for some communications port. You should be able to specify a timeout when you call Read(). Or maybe you can specify the timeout when you open the communications port. Or maybe it's not a communications port but something as simple as polling a flag bit. In that case you should not poll the flag forever. Give up after the timeout. – kkrambo Jun 15 '12 at 20:21
0

You should be using Thread.Abort instead of Interrupt. For your further clarifiation look at this thread Abort Vs Interrupt

This should resolve your issue.

Community
  • 1
  • 1
Tabish Sarwar
  • 1,505
  • 1
  • 11
  • 18
  • You can't call abort from another thread to end a separate thread. Well you can, but it will just abort the thread calling it (which would be the main thread...) – B_Moore Jun 15 '12 at 18:03
  • Well in that case you should be implementing a timeout pattern for your asynchronous thread . Take a look this http://stackoverflow.com/questions/710070/timeout-pattern-how-bad-is-thread-abort-really. This is just an idea . I believe somthing around this might help you in your case. – Tabish Sarwar Jun 15 '12 at 18:08
  • Unfortunately, this thread is trying to obtain data for me (it responds to a boolean). That thread doesn't outline any ways of maintaining data validity. If I set the boolean volatile, the abort/suspended thread seems to not be letting go of the lock, but if i leave it non-volatile it has a chance to corrupt. – B_Moore Jun 15 '12 at 18:30
  • I am trying to suggest you this things . Your thread is waiting to get some data .Are you trying to modify some data. I guess not. This is waht i am understanding here . When you invoke the thread. Set it to throw some timout exception itself rathering than you trying to interrupt it. http://stackoverflow.com/questions/1540444/how-to-report-timeout-in-asynchronous-call . Can you post some code here if possible. – Tabish Sarwar Jun 15 '12 at 18:47