Debug.WriteLine woes

[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(o bject sender, System.EventArg s e)

{

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

t.Name = "Tubo";

t.Start();

}

private void button2_Click(o bject sender, System.EventArg s e)

{

//Debug.WriteLine (t.ThreadState) ;

Debug.WriteLine ("Tubo");

}

}

public class Tubo

{

public void Execute()

{

while( true)

{

Thread.CurrentT hread.Suspend() ;

}

}

}

[pokémon]

Re: Debug.WriteLine woes

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

Suspend() is the problem, not Debug.WriteLine (), and maybe someone else can
explain why...

[Willy Denoyette [MVP]]

Re: Debug.WriteLine woes

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.CurrentT hread.Suspend() ;
}


Willy.

"Miha Markic" <msdn@spin.si > wrote in message news:%23KjObu%2 3cDHA.3948@TK2M SFTNGP11.phx.gb l...[color=blue]
> Hi,
>
> Hmmm, is this only debug time problem?
>
> --
> Miha Markic - DXSquad
>
> Developer Express newsgroups are for peer-to-peer support.
> For direct support from Developer Express, write to support@devexpr ess.com
> Bug reports should be directed to: support@devexpr ess.com
> Due to newsgroup guidelines, DX-Squad will not answer anonymous postings.
>
> "pokémon" <poke@mon.com > wrote in message
> news:m616b.10$K X6.7@nwrdny03.g nilink.net...[color=green]
> > Don't use Suspend(), use synchronization mechanisms.
> >
> > Suspend() is the problem, not Debug.WriteLine (), and maybe someone else[/color]
> can[color=green]
> > explain why...
> >
> >[/color]
>
>[/color]

[Daniel O'Connell]

Re: Debug.WriteLine woes


"Miha Markic" <msdn@spin.si > wrote in message
news:%23KjObu%2 3cDHA.3948@TK2M SFTNGP11.phx.gb l...[color=blue]
> Hi,
>
> Hmmm, is this only debug time problem?
>[/color]
Appears to be... I wonder if its something to do with a listener or a
listener lock...[color=blue]
> --
> Miha Markic - DXSquad
>
> Developer Express newsgroups are for peer-to-peer support.
> For direct support from Developer Express, write to support@devexpr ess.com
> Bug reports should be directed to: support@devexpr ess.com
> Due to newsgroup guidelines, DX-Squad will not answer anonymous postings.
>
> "pokémon" <poke@mon.com > wrote in message
> news:m616b.10$K X6.7@nwrdny03.g nilink.net...[color=green]
> > Don't use Suspend(), use synchronization mechanisms.
> >
> > Suspend() is the problem, not Debug.WriteLine (), and maybe someone else[/color]
> can[color=green]
> > explain why...
> >
> >[/color]
>
>[/color]

[Miha Markic]

Re: Debug.WriteLine woes

Hi Willy,

"Willy Denoyette [MVP]" <willy.denoyett e@pandora.be> wrote in message
news:O9P4oi$cDH A.3240@TK2MSFTN GP11.phx.gbl...[color=blue]
> No it is not.
> The CLR will only suspend the thread when HE considers it is safe to do so[/color]
(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.
[color=blue]
> In your code.... it looks like the CLR considers it is not safe to suspend[/color]
the thread so you loop indefinitely consuming all CPU[color=blue]
> resources...
>[/color]

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

[color=blue]
> while( true)
> {
> Thread.CurrentT hread.Suspend() ;
> }
>
>[/color]
Thanks,
Miha

[Miha Markic]

Re: Debug.WriteLine woes

Hi Daniel,
[color=blue][color=green]
> > Hmmm, is this only debug time problem?
> >[/color]
> Appears to be... I wonder if its something to do with a listener or a
> listener lock...[/color]

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

[Daniel O'Connell]

Re: Debug.WriteLine woes


"Miha Markic" <msdn@spin.si > wrote in message
news:OnAvexDdDH A.2672@tk2msftn gp13.phx.gbl...[color=blue]
> Hi Daniel,
>[color=green][color=darkred]
> > > Hmmm, is this only debug time problem?
> > >[/color]
> > Appears to be... I wonder if its something to do with a listener or a
> > listener lock...[/color]
>
> 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[/color]
was[color=blue]
> called.
> That makes me assume that it has something to do with debugger (since the
> situation only occurs withing VS.NET 2003)
>[/color]

Ya, thats my best guess too...very interesting and odd thing to have happen,
I must say.
[color=blue]
> Miha
>
>[/color]

[Miha Markic]

Re: Debug.WriteLine woes

[color=blue]
> Ya, thats my best guess too...very interesting and odd thing to have[/color]
happen,[color=blue]
> I must say.[/color]

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

Miha

[pokémon]

Re: Debug.WriteLine woes

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.Interrup t on the blocked thread to throw a
ThreadInterrupt edException, which breaks the thread out of the blocking
call. The thread should catch the ThreadInterrupt edException and do whatever
is appropriate to continue working. If the thread ignores the exception, the
runtime catches the exception and stops the thread.

[Miha Markic]

Re: Debug.WriteLine woes

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

"pokémon" <poke@mon.com > wrote in message
news:41G7b.1216 3$KX6.10335@nwr dny03.gnilink.n et...[color=blue]
> Regardless of why the problem is occurring, there is still no reason to[/color]
use[color=blue]
> Thread.Suspend( ).
>
> Read the MSDN topic "Pausing and Resuming Threads." Here is an excerpt:
>[/color]