Debug.WriteLine woes

  • Thread starter Thread starter Miha Markic
  • Start date Start date
M

Miha Markic

Hi,

I've found a strange problem regarding Debug.WriteLine and Thread in
suspended state.
Create a thread, start it and make it suspended.
Then try Debug.WriteLine - it will start 100% CPU usage while not blocking
the main thread.
Code is below (create a from with two buttons).
Steps:
Click on button1 (starts and suspends the thread). Then click on button2.
You'll note the CPU usage goes to sky.
This only occurs if the thread is suspended.

Miha

private void button1_Click(object sender, System.EventArgs e)

{

t = new Thread(new ThreadStart(new Tubo().Execute));

t.Name = "Tubo";

t.Start();

}

private void button2_Click(object sender, System.EventArgs e)

{

//Debug.WriteLine(t.ThreadState);

Debug.WriteLine("Tubo");

}

}

public class Tubo

{

public void Execute()

{

while( true)

{

Thread.CurrentThread.Suspend();

}

}

}
 
Don't use Suspend(), use synchronization mechanisms.

Suspend() is the problem, not Debug.WriteLine(), and maybe someone else can
explain why...
 
No it is not.
The CLR will only suspend the thread when HE considers it is safe to do so (see description of Thread.Suspend in MSDN).
In your code.... it looks like the CLR considers it is not safe to suspend the thread so you loop indefinitely consuming all CPU
resources...

while( true)
{
Thread.CurrentThread.Suspend();
}


Willy.
 
Miha Markic said:
Hi,

Hmmm, is this only debug time problem?
Click to expand...
Appears to be... I wonder if its something to do with a listener or a
listener lock...
 
Hi Willy,

Willy Denoyette said:
No it is not.
The CLR will only suspend the thread when HE considers it is safe to do so
Click to expand...
(see description of Thread.Suspend in MSDN).

Sorry, you are wrong here. This happens only when the Suspend is called from
within another thread.
If the suspend is called from the executing thread then it suspends right
away.
In your code.... it looks like the CLR considers it is not safe to suspend
Click to expand...
the thread so you loop indefinitely consuming all CPU
resources...
Click to expand...

Nope.
The thread suspends just fine. The problem arises only when I call
Debug.WriteLine.

while( true)
{
Thread.CurrentThread.Suspend();
}
Click to expand...
Thanks,
Miha
 
Hi Daniel,
Appears to be... I wonder if its something to do with a listener or a
listener lock...
Click to expand...

It appears so. However, I've checked the WriteLine code and it doesn't do
anything like 100% usage.
Furthermore, "100% usage" thread is not the one from where the WriteLine was
called.
That makes me assume that it has something to do with debugger (since the
situation only occurs withing VS.NET 2003)

Miha
 
Miha Markic said:
Hi Daniel,


It appears so. However, I've checked the WriteLine code and it doesn't do
anything like 100% usage.
Furthermore, "100% usage" thread is not the one from where the WriteLine was
called.
That makes me assume that it has something to do with debugger (since the
situation only occurs withing VS.NET 2003)
Click to expand...

Ya, thats my best guess too...very interesting and odd thing to have happen,
I must say.
 
Ya, thats my best guess too...very interesting and odd thing to have happen,
I must say.
Click to expand...

Hehe, yeah. I've posted now the same question in vsnet.debugging.
I hope somebody from MS will read it.

Miha
 
Regardless of why the problem is occurring, there is still no reason to use
Thread.Suspend().

Read the MSDN topic "Pausing and Resuming Threads." Here is an excerpt:

*****
The Suspend and Resume methods are not generally useful for applications,
and should not be confused with synchronization mechanisms. Because Suspend
and Resume do not rely on the cooperation of the thread being controlled,
they are highly intrusive and can result in serious application problems
like deadlocks (for example, if you suspend a thread that holds a resource
that another thread will need). Some applications do need to control the
priority of threads for better performance. To do this, you should use
Thread.Priority rather than Thread.Suspend.
You can block threads in a number of ways. For example, you can have a
thread wait for another thread to stop by calling Thread.Join. You can have
a thread wait for access to a synchronized object using Monitor.Wait, or you
can put it to sleep using Thread.Sleep. You can interrupt a waiting thread
by calling Thread.Interrupt on the blocked thread to throw a
ThreadInterruptedException, which breaks the thread out of the blocking
call. The thread should catch the ThreadInterruptedException and do whatever
is appropriate to continue working. If the thread ignores the exception, the
runtime catches the exception and stops the thread.
 
Yup, I've already know that.
Anyway, thanks for info.
I could use and will probably use some sort of monitors.
Though suspending/resuming is easier IMO (mind that I suspend from within
executing thread and I won't hold any resource - just wait for anybody to
wake the thread up).

And still there is a bug somewhere deep down in vs.net...

Miha
 
Back
Top