Re: Threading question

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Kevin Spencer (kspencer_at_takempis.com)
Date: 09/28/04 

Date: Tue, 28 Sep 2004 16:40:53 -0400

Hi John,

I have used multi-threading in enterprise-level ASP.Net apps with no
problems whatsoever. However, that wasn't my point. My point was that your
use of Threading is equivalent to not using Threading at all, except for the
extra overhead. Your app will respond in almost exactly the same time as if
you hadn't used Threading at all.

A program has a main execution thread, which is sequential. It executes
exactly ONE instruction at a time. When a function is called, execution
jumps to the function, and continues until the function exits, and the
execution moves back to the calling function. Your technique does exactly
that, but in a more complex manner. You spawn a thread, and put the current
thread to sleep until it is finished processing.

Think of it this way. You are a thread, sitting at home, going about your
business, let's say, cleaning house. Now, you need to buy something from the
store.

Non-threaded: You go to the store to buy something. When you're done, you
come home and go back to work.

Your Threaded: You send your wife to the store to buy something. While she's
gone, you take a nap. When she gets back, you go back to work.

Properly Threaded: You send your wife to the store to buy something, while
you continue working. When she gets back, you continue working.

Note that the outcome of the first 2 situations is the same. You might just
as well have gone to the store yourself. You accomplished the same amount of
work in the time that you would have if you hadn't sent her at all.

Okay, now imagine that you're not a thread, but a string. While your wife is
gone to the store, you muss your hair until it is all matted and knotty.
When your wife gets home, she doesn't recognize you, and cries "I thought
you were a string!" You reply "I'm a frayed knot." ;-) 

-- 
HTH,
Kevin Spencer
.Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living
"John" <jsparrowNOSPAM@ecclesdeletethiscollege.ac.uk> wrote in message
news:uK8XsYZpEHA.800@TK2MSFTNGP14.phx.gbl...
> Thanks for the reply Kevin,
>
> Try writing a button click event handler (ASP.NET) that does:
>
> private void Button_Click()
> {
> DateTime d = DateTime.Now.AddSeconds(20);
> while (DateTime.Now < d) ;
> }
>
> Then try something like:
>
> private void AnotherButton_Click()
> {
> Thread th = new Thread(new ThreadStart(DoSomething));
> th.Start();
> th.Join();
> }
>
> private void DoSomething()
> {
> DateTime d = DateTime.Now.AddSeconds(20);
> while (DateTime.Now < d) ;
> }
>
> Try to use other webapps while these are running.... weird!
>
> It's been discussed at length before (before anyone tells me it's stupid
to
> sit in a tight loop for 20 seconds!!!).
>
> In my real app I'm crunching numbers (entirely in C#, no SQL involved at
> this stage). It only takes a couple of seconds (no chance of browser
> timeout) but there seems to be a noticable performance change for other
.NET
> stuff on the server.
>
> Thanks,
>
> John
>
>
>
> "Kevin Spencer" <kspencer@takempis.com> wrote in message
> news:uNGVKnYpEHA.3196@tk2msftngp13.phx.gbl...
> > What you've designed is threading without any of the benefits of
> > threading.
> > You create a thread, and then sleep the main thread until it is
finished.
> > This is exactly equivalent to not creating a new thread at all. The
> > purpose
> > of threading is to allow 2 different tasks to be executed at the same
> > time.
> >
> > -- 
> > HTH,
> > Kevin Spencer
> > .Net Developer
> > Microsoft MVP
> > I get paid good money to
> > solve puzzles for a living
> >
> > "John" <jsparrowNOSPAM@ecclesdeletethiscollege.ac.uk> wrote in message
> > news:O#TYpTYpEHA.3364@TK2MSFTNGP10.phx.gbl...
> >> I've got some reasonably complex business logic in my C# code, in a
class
> >> called by a ASP.NET page. This takes around 3-4 seconds to execute.
It's
> > not
> >> dependent on SQL calls or anything like that.
> >>
> >> I know of the problems with the worker process doing two things at once
> > from
> >> the main thread pool (The old "Sit in a tight loop for 20 seconds and
> > watch
> >> all your webapps die!" issue). So I've worked around the issue by
> >> spawning
> >> the business logic into a new thread. The main thread Sleep()'s until
> >> it's
> >> finished, and then continues. eg:
> >>
> >> Button_Click:
> >> 1) start new thread
> >> 2) Sleep until it's done
> >> 3) destroy it
> >>
> >> New thread:
> >> 1) Do something heavy for a few seconds
> >> 2) terminate
> >>
> >> I figured that, since the main thread is sleeping waiting for my new
> > thread,
> >> I don't need to lock() any objects, I can just access then directly.
> >>
> >> It all seems to work fine, and has solved the strange delays my other
> >> webapp-users were experiencing.
> >>
> >> Does this sound like good practice?
> >>
> >> Thanks,
> >>
> >> John
> >>
> >>
> >
> >
>
>
Quantcast