By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,911 Members | 1,137 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,911 IT Pros & Developers. It's quick & easy.

Is this multi-thread? Yes, then why lock doesn't work? No? then how C# handle threads?

P: n/a
I found a interesting problem in C# and couldn't explain it.

The code to reproduce it is very simple:
1. Create a windows application in C#.
2. Listen to the activated event on the default form --- Form1.cs
3. Create a method DoUpdate() which will popup two dialog boxes "Dialog box
one" and "Dialog box two".
4. Call DoUpdate() in the activated event handling.

It will look like the following:
private void Form1_Activated(object sender, System.EventArgs e)
{
this.DoUpdate();
}

private void DoUpdate()
{
lock(this)
{
MessageBox.Show("Dialog box one");
MessageBox.Show("Dialog box two");
}
}

Then, take a guess what will happen after you run the application when you
switch between windows on your machine. The result is pretty supprising for
me. Instead of showing "Dialog box one" and "Dialog box two" in turn as I
expected for a multi-thread situation, it keeps looping "Dialog box one". I
replaced this by another self defined object which doesn't solve the
problem.
If this is a single thread case(get rid of the lock in DoUpdate), the result
is the same. How can it jump from "Dialog box one" to Activated event
without finishing DoUpdate.

Our guess is C# keeping the excuting methods in a stack and somehow gives
the event handling a higher priority.
Could anyone explain this?

-Jinlin
Jul 21 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Hi,

Firstly merely adding a lock does not make this multithreaded, with or
without the lock this is single threaded code. With the lock DoUpdate is
merely thread safe.

This behaviour is not entirely unexpected, the Activated event is raised
when the WM_ACTIVATE with the low word of the wParam = WA_ACTIVE or
WA_CLICKACTIVE, this occurs when ever the window becomes active and in your
case that happens when the message box is dismissed, the message queue
receives a WM_ACTIVATE message and even though the primary message pump is
not running because of the modal message box, modal forms have there own
message pump that processes the message queue and it dispatches the
WM_ACTIVATE message to the form causing the Activate event to be raised.

Hope this helps

--
Chris Taylor
http://www.xanga.com/home.aspx?user=taylorza
"Jinlin" <ji*********@unisys.com> wrote in message
news:uu**************@TK2MSFTNGP09.phx.gbl...
I found a interesting problem in C# and couldn't explain it.

The code to reproduce it is very simple:
1. Create a windows application in C#.
2. Listen to the activated event on the default form --- Form1.cs
3. Create a method DoUpdate() which will popup two dialog boxes "Dialog box one" and "Dialog box two".
4. Call DoUpdate() in the activated event handling.

It will look like the following:
private void Form1_Activated(object sender, System.EventArgs e)
{
this.DoUpdate();
}

private void DoUpdate()
{
lock(this)
{
MessageBox.Show("Dialog box one");
MessageBox.Show("Dialog box two");
}
}

Then, take a guess what will happen after you run the application when you
switch between windows on your machine. The result is pretty supprising for me. Instead of showing "Dialog box one" and "Dialog box two" in turn as I
expected for a multi-thread situation, it keeps looping "Dialog box one". I replaced this by another self defined object which doesn't solve the
problem.
If this is a single thread case(get rid of the lock in DoUpdate), the result is the same. How can it jump from "Dialog box one" to Activated event
without finishing DoUpdate.

Our guess is C# keeping the excuting methods in a stack and somehow gives
the event handling a higher priority.
Could anyone explain this?

-Jinlin

Jul 21 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.