Multiple Threads Within the IDE

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

My only tips would be to not rely on console apps (not much of a real-world
scenario) and move your thread code out from within the Form's class code
and into its own class (as you'd probably see in the real world). I found
out a bunch of scope stuff that changes once you try and do delegates off of
methods within classes, rather than just a method within the Form class.
I'll certainly do the latter - that's a good point. I prefer console
apps for demonstration purposes because they don't involve a load of
extra "cruft" - virtually all the code you see is relevant to the point
I'm trying to demonstrate. (Almost all the samples are doing non-real-
world things, but to give building blocks which will help in the real
world. In my experience, sample code which tries to be very real-world
oriented ends up being either confusing or useful for anything other
than that oe particular situation.) Maybe an explanatory paragraph
saying that kind of thing would be helpful.
I'd also recommend somehow that you get the word out about your article. It
doesn't hit very high in Google, and the one's that do are the articles I'm
complaining about right now - the ones that just show console apps with no
meat, no talk about how to safely update the UI from a worker thread, and
how to safely bring down worker threads.

Right. Word is gradually spreading about the article, and I'll keep
plugging it when there are questions about it. Not entirely sure where
else to "advertise" it, to be honest - but any ideas are welcome.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Interrupt will only throw the exception when the thread is in an alertable state (Sleeping, waiting on a synchronization primitive or attempting to joion with another thread). This is how it ensures that the exception doesn't do the damage that Abort can do.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<##************ **@tk2msftngp13 .phx.gbl>

Maybe I missed this in your article (but I don't think so), but ... Is there
a reason that a ThreadInterrupt edException does not get raised in a worker
thread if that worker thread just loops without having a Thread.Sleep
command somewhere in the worker thread's loop (even if the Thread is marked
for background before it's started)?

I would've thought that a Sleep wasn't necessary when marking it as
IsBackground before starting it, but until I put at least a Thread.Sleep(0)
(thus giving up at least that timeslice within the loop), my
Thread.Interrup t() from the main thread never generates an exception within
the try...catch clause of my worker thread that surrounds the loop.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

A thread ends when it exists the function that it is executing. If the
thread performs a continuos loop you usually use a boolean to control the
execution, something like:

bool run;

void Foo()
{
while( run )
{
// perform whatever
}
}

So what I do to stop and end the thread in a clean way is:

run = false;

this makes the executuion flow to exit the function and end the thread.

regards,
Santiago Corredoira.

How about on your blog, and then try and get references to it on some of the
other major blogs (like Scobleizer, etc).

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

My only tips would be to not rely on console apps (not much of a
real-world
scenario) and move your thread code out from within the Form's class code
and into its own class (as you'd probably see in the real world). I
found
out a bunch of scope stuff that changes once you try and do delegates off
of
methods within classes, rather than just a method within the Form class.

I'll certainly do the latter - that's a good point. I prefer console
apps for demonstration purposes because they don't involve a load of
extra "cruft" - virtually all the code you see is relevant to the point
I'm trying to demonstrate. (Almost all the samples are doing non-real-
world things, but to give building blocks which will help in the real
world. In my experience, sample code which tries to be very real-world
oriented ends up being either confusing or useful for anything other
than that oe particular situation.) Maybe an explanatory paragraph
saying that kind of thing would be helpful.

I'd also recommend somehow that you get the word out about your article.
It
doesn't hit very high in Google, and the one's that do are the articles
I'm
complaining about right now - the ones that just show console apps with
no
meat, no talk about how to safely update the UI from a worker thread, and
how to safely bring down worker threads.

Right. Word is gradually spreading about the article, and I'll keep
plugging it when there are questions about it. Not entirely sure where
else to "advertise" it, to be honest - but any ideas are welcome.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

So, when the OS interrupts the thread because it's gone past its timeslice,
it's not in the WaitSleepJoin state? What state would the thread be in when
the OS is the one who pre-empts it to run other stuff?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:b1******** *************** *********@4ax.c om...

Hi Doug:

The thread cannot be interrupted until it blocks (ThreadState =
WaitSleepJoin).

--
Scott
http://www.OdeToCode.com/

On Fri, 8 Oct 2004 21:04:27 -0500, "Doug Thews"
<do*******@remo veme.ddconsult. com> wrote:

Maybe I missed this in your article (but I don't think so), but ... Is
there
a reason that a ThreadInterrupt edException does not get raised in a worker
thread if that worker thread just loops without having a Thread.Sleep
command somewhere in the worker thread's loop (even if the Thread is
marked
for background before it's started)?

I would've thought that a Sleep wasn't necessary when marking it as
IsBackgroun d before starting it, but until I put at least a
Thread.Sleep( 0)
(thus giving up at least that timeslice within the loop), my
Thread.Interr upt() from the main thread never generates an exception
within
the try...catch clause of my worker thread that surrounds the loop.

Thread.Interrup t is a 'soft interrupt', probably implemented by
setting a flag the runtime can check at specific times (before a
thread enters a blocked state, for instance). In fact, the name
interrupt might be a poor choice, except for the fact that we are so
far removed from interrupts with a managed runtime underneath.

The OS uses hardware (the clock) to interrupt a running thread and
make scheduling decisions. If the OS selects another thread it can
perform a context switch, which is saving the current thread's state
(program counter, registers, and other goo) onto the thread's kernel
mode stack, and restoring the same information from the second
thread's kernel mode stack. That's the simplest view, of course.

--
Scott
http://www.OdeToCode.com/

On Sat, 9 Oct 2004 11:19:12 -0500, "Doug Thews"
<do*******@remo veme.ddconsult. com> wrote:

So, when the OS interrupts the thread because it's gone past its timeslice,
it's not in the WaitSleepJoin state? What state would the thread be in when
the OS is the one who pre-empts it to run other stuff?

You're looking at this slightly too low level. What the thread schedular is doing is to some degree irrelevant to you unless you want to give up your timeslice, change priorities, etc.

The crucial thing is to think of the situation as having an infinite number of processors available. In other words your thread will appear to other threads in the state it would be if it were being scheduled (in other words thread scheduling has no effect on your thread's state).

If you try to second guess the thread scheduler its a sure fire way of introducing timing related bugs.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<OG************ **@TK2MSFTNGP09 .phx.gbl>

So, when the OS interrupts the thread because it's gone past its timeslice,
it's not in the WaitSleepJoin state? What state would the thread be in when
the OS is the one who pre-empts it to run other stuff?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

OK, thanks. I wasn't expecting to have to give up my timeslice periodically
just to allow a ThreadInterrupt edException to be generated the next time my
thread gets a timeslice, but I understand what you guys are trying to say.

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

"Richard Blewett [DevelopMentor]" <ri******@devel op.com> wrote in message
news:u8******** ******@TK2MSFTN GP11.phx.gbl...

You're looking at this slightly too low level. What the thread schedular
is doing is to some degree irrelevant to you unless you want to give up
your timeslice, change priorities, etc.

The crucial thing is to think of the situation as having an infinite
number of processors available. In other words your thread will appear to
other threads in the state it would be if it were being scheduled (in
other words thread scheduling has no effect on your thread's state).

If you try to second guess the thread scheduler its a sure fire way of
introducing timing related bugs.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog
nntp://news.microsoft. com/microsoft.publi c.dotnet.langua ges.csharp/<OG************ **@TK2MSFTNGP09 .phx.gbl>

So, when the OS interrupts the thread because it's gone past its
timeslice,
it's not in the WaitSleepJoin state? What state would the thread be in
when
the OS is the one who pre-empts it to run other stuff?

--
Doug Thews
Director, Customer Solutions
D&D Consulting Services
----------------
Visit my Tech Blog at:
http://www.ddconsult.com/blogs/illuminati/

Santi <__***********@ ibcentre.es> wrote:

A thread ends when it exists the function that it is executing. If the
thread performs a continuos loop you usually use a boolean to control the
execution, something like:

bool run;

void Foo()
{
while( run )
{
// perform whatever
}
}

So what I do to stop and end the thread in a clean way is:

run = false;

this makes the executuion flow to exit the function and end the thread.

Note that as written, this isn't thread-safe. Either run should be made
volatile, or you should put a lock round both the reading and writing
of it.

See http://www.pobox.com/~skeet/csharp/t...latility.shtml

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Doug Thews <do*******@remo veme.ddconsult. com> wrote:

How about on your blog, and then try and get references to it on some of the
other major blogs (like Scobleizer, etc).

I don't have a blog - but people probably see more references to the
article in the newsgroups than would read a blog anyway :)

I guess I could see whether any other blogs fancied commenting on it.
I'll have a think - thanks for the suggestion :)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too