How to trigger other thread

  • Thread starter Thread starter Axel Dahmen
  • Start date Start date
A

Axel Dahmen

Hi,

I've two threads in my program: 1) The original program thread and 2) a
worker thread.

For simplicity my worker thread writes its output into the static controls
and status bar by itself.

In the Form_Closing() event, I want to shut down my worker thread gracefully
and wait for its completion (see code #1 below). The while loop at the end
of Form_Closing() never exits, apparently because in my worker thread hangs
updating a status bar panel. It appears to me that updating the status bar
during executing the Form_Closing() event won't work.

What should I do?

How can I trigger some event in the original thread to have the status bar
updated from there?

TIA,
Axel Dahmen


------

code #1:

private void MainForm_Closing(...)
{
if (m_running) m_running=false; // semaphore. Ends while-loop in 2nd
thread
while (m_thread!=null && m_thread.IsAlive) Thread.Sleep(100);
}
 
When you wait for the other thread to exit, you are not processing your
message queue and as a result there is a deadlock. The worker sends messages
to the main thread when it tries to update the status bar, but the main
thread does not pump messages.

-Atul
http://www.ssware.com/
Shell MegaPack - Windows Explorer Shell Controls for ActiveX and .Net
 
If you wrap the thread proc in a class you can pass parameters to it.

class ThreadWrapper()
{
public bool Stop = false;

public void ThreadProc()
{
do {
// stuff
} while ( Stop == false );
}
}

To start the thread...
wrapper = new ThreadWrapper();
theThread = new Thread(new ThreadStart(wrapper.ThreadProc()):
theThread.Start():

To quit the app...
wrapper.Stop = true;
theThread.Join();
Application.Exit();

David
 
Axel Dahmen said:
I've two threads in my program: 1) The original program thread and 2) a
worker thread.

For simplicity my worker thread writes its output into the static controls
and status bar by itself.
Click to expand...

<snip>

It looks like your solution - at that provided by aualias - aren't
thread-safe. They assume that when one thread changes the value of a
variable, all other threads see that value change.

See http://www.pobox.com/~skeet/csharp/threads/volatility.shtml for why
that's a bad assumption, and
http://www.pobox.com/~skeet/csharp/threads/shutdown.shtml for a cleaner
way to shut down a thread.
 
Jon,

I can't get through to your website, but would like to see your solution.
Is your site down, or is the problem at my end?

I was assuming that there are only two threads in the application.
Obviously, if there are other threads, they will not be able to see the
variable if it is not static.

David
 
aualias said:
I can't get through to your website, but would like to see your solution.
Is your site down, or is the problem at my end?
Click to expand...

There was a problem with pobox.com yesterday - it should work now.
I was assuming that there are only two threads in the application.
Obviously, if there are other threads, they will not be able to see the
variable if it is not static.
Click to expand...

No, the problem isn't the visibility of the variable - it's whether
updates are "seen" or not.
 
Interesting...

I had no idea. It is simple enough to take precautions (and foolish not
to), but do you have any idea how likely it is that this would occur? If it
were a huge issue, I would think that I would have heard about it before.

David
 
aualias said:
Interesting...

I had no idea. It is simple enough to take precautions (and foolish not
to), but do you have any idea how likely it is that this would occur? If it
were a huge issue, I would think that I would have heard about it before.
Click to expand...

There was a thread about this which demonstrated the problem very
neatly in the C# group, called "threads, static variables". Here's the
program which demonstrated the problem:

using System;
using System.Threading;

public class Test {

static int i = 0;

public static void Main(string [] args) {
new Thread(new ThreadStart(t1)).Start();
new Thread(new ThreadStart(t2)).Start();
}

static void t1() {
int j = 0;
while(i == 0) {
j++;
}
}

static void t2() {
i = 1;
}

}

Compile with csc /o+ Test.cs. One would expect the program to terminate
almost immediately, but it never does (unless you're unlucky and t2
actually starts before t1).
 
Thanks, Jon, your information is very enlightening!

I've read through MSDN on volatile variables now but there is one
contradiction to what your website says. In your discussion about locking
and volatile variables you say that volatile variables would prevent caching
but not straighten the sequence of reads/writes. MSDN says differently. They
speak of volatile variables having acquire and release semantics at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html
/vclrfcsharpspec_10_4_3.asp

thus ordering reads and writes. So explicitly locking a simple semaphore
won't be necessary.

I'm confused. What's your opinion?

Regards,
Axel Dahmen


-------------------
Jon Skeet said:
aualias said:
Interesting...

I had no idea. It is simple enough to take precautions (and foolish not
to), but do you have any idea how likely it is that this would occur? If it
were a huge issue, I would think that I would have heard about it
Click to expand...
before.

There was a thread about this which demonstrated the problem very
neatly in the C# group, called "threads, static variables". Here's the
program which demonstrated the problem:

using System;
using System.Threading;

public class Test {

static int i = 0;

public static void Main(string [] args) {
new Thread(new ThreadStart(t1)).Start();
new Thread(new ThreadStart(t2)).Start();
}

static void t1() {
int j = 0;
while(i == 0) {
j++;
}
}

static void t2() {
i = 1;
}

}

Compile with csc /o+ Test.cs. One would expect the program to terminate
almost immediately, but it never does (unless you're unlucky and t2
actually starts before t1).
Click to expand...
 
Axel Dahmen said:
Thanks, Jon, your information is very enlightening!

I've read through MSDN on volatile variables now but there is one
contradiction to what your website says. In your discussion about locking
and volatile variables you say that volatile variables would prevent caching
but not straighten the sequence of reads/writes. MSDN says differently. They
speak of volatile variables having acquire and release semantics at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html
/vclrfcsharpspec_10_4_3.asp

thus ordering reads and writes. So explicitly locking a simple semaphore
won't be necessary.

I'm confused. What's your opinion?
Click to expand...

Can't easily reply right now - my laptop is falling apart and I'm about
to go on holiday. Will try to remember to reply in a week or so.
 
Back
Top