[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.sdk

Multithreading in .NET

Peter Hurford

1/7/2003 11:17:00 PM

Have got a C# application and am looking at ways to
improve performance.

I've found an area of code where there's some work I need
to do, but where the user is going to get the same
response regardless of the outcome. Also, this chunk of
work could be quite slow since it involves an http
request/response over the internet.

Seems like a classic case of spawning this piece of work
in a new thread, and that's what I've attempted to do. The
only thing is, I need to pass some parameters into the new
thread. It's all quite lightweight - just a couple of
strings.

I'm new to multithreading under .NET and was wondering
what was the best approach to take? I know there are a
couple of ways to solve this, but which would be the best
approach, and why?

TIA
3 Answers

Christoph Schittko

1/9/2003 5:42:00 AM

0

The best way IMHO would be to use the ThreadPool.QueueUserWorkItem() method,
because you don't even have to worry about spawning the thread. The syntax
is something like:

ThreadPool.UnsafeQueueUserWorkItem(
new WaitCallback( MyAsyncMethod ), new MyAsyncParams( p1, p2,
p3 ) );

The ThreadPool will execute the method pointed to by the WaitCallback
delegate and pass it the second parameter. In the example above it's using a
custom class to wrap several parameters that are passed to the method
invoked through the delegate.

Using the ThreadPool will even save you the extra overhead associated with
creating a new thread since the delegate is invoked on a thread in a thread
pool controlled by the .NET Framework, but on the downside, you don't have
control is you want to pause the running thread for any reason.

An alternative to QueueUserWorkItem is to invoke a method through an
asynchronous delegate. This topic is pretty well covered in the Framework
Documentation under Programming With The .NET Framework->Including
Asynchronous Calls [1]. Again, you don't have to worry about controlling the
threads on which your method executes, because the framework runs it in a
thread pool thread.

HTH,
--
Christoph Schittko
Software Architect

[1]
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconasynchronousprogramming.asp?...

"Peter Hurford" <peter.hurford@microcrest.com> wrote in message
news:0e8b01c2b69a$8c8747d0$d3f82ecf@TK2MSFTNGXA10...
> Have got a C# application and am looking at ways to
> improve performance.
>
> I've found an area of code where there's some work I need
> to do, but where the user is going to get the same
> response regardless of the outcome. Also, this chunk of
> work could be quite slow since it involves an http
> request/response over the internet.
>
> Seems like a classic case of spawning this piece of work
> in a new thread, and that's what I've attempted to do. The
> only thing is, I need to pass some parameters into the new
> thread. It's all quite lightweight - just a couple of
> strings.
>
> I'm new to multithreading under .NET and was wondering
> what was the best approach to take? I know there are a
> couple of ways to solve this, but which would be the best
> approach, and why?
>
> TIA

Peter Hurford

1/10/2003 12:37:00 PM

0

Looks an ideal mechanism.

Have had a very quick look at this and whilst I can queue
my task OK, the runtime then seems to wander off into the
wild blue yonder and my task doesn't get executed.

Multithreaded debugging - dontcha just love it? Looks like
its just as much fun under .net as it ever was!

P

>-----Original Message-----
>The best way IMHO would be to use the
ThreadPool.QueueUserWorkItem() method,
>because you don't even have to worry about spawning the
thread. The syntax
>is something like:
>
>ThreadPool.UnsafeQueueUserWorkItem(
> new WaitCallback( MyAsyncMethod ), new
MyAsyncParams( p1, p2,
>p3 ) );
>
>The ThreadPool will execute the method pointed to by the
WaitCallback
>delegate and pass it the second parameter. In the example
above it's using a
>custom class to wrap several parameters that are passed
to the method
>invoked through the delegate.
>
>Using the ThreadPool will even save you the extra
overhead associated with
>creating a new thread since the delegate is invoked on a
thread in a thread
>pool controlled by the .NET Framework, but on the
downside, you don't have
>control is you want to pause the running thread for any
reason.
>
>An alternative to QueueUserWorkItem is to invoke a method
through an
>asynchronous delegate. This topic is pretty well covered
in the Framework
>Documentation under Programming With The .NET Framework-
>Including
>Asynchronous Calls [1]. Again, you don't have to worry
about controlling the
>threads on which your method executes, because the
framework runs it in a
>thread pool thread.
>
>HTH,
>--
>Christoph Schittko
>Software Architect
>
>[1]
>http://msdn.microsoft.com/l...
us/cpguide/html/cpconasynchronousprogramming.asp?frame=true
>
>"Peter Hurford" <peter.hurford@microcrest.com> wrote in
message
>news:0e8b01c2b69a$8c8747d0$d3f82ecf@TK2MSFTNGXA10...
>> Have got a C# application and am looking at ways to
>> improve performance.
>>
>> I've found an area of code where there's some work I
need
>> to do, but where the user is going to get the same
>> response regardless of the outcome. Also, this chunk of
>> work could be quite slow since it involves an http
>> request/response over the internet.
>>
>> Seems like a classic case of spawning this piece of work
>> in a new thread, and that's what I've attempted to do.
The
>> only thing is, I need to pass some parameters into the
new
>> thread. It's all quite lightweight - just a couple of
>> strings.
>>
>> I'm new to multithreading under .NET and was wondering
>> what was the best approach to take? I know there are a
>> couple of ways to solve this, but which would be the
best
>> approach, and why?
>>
>> TIA
>
>
>.
>

Christoph Schittko

1/10/2003 4:36:00 PM

0

Can you set a breakpoint at the top the method you are queueing ? Does it
get hit? I haven't had any problems with this in the past and I use it quite
a bit, managed and unmanaged ...

--
Christoph Schittko
Software Architect

"Peter Hurford" <peter.hurford@microcrest.com> wrote in message
news:34c801c2b89c$a6eb4280$8df82ecf@TK2MSFTNGXA02...
> Looks an ideal mechanism.
>
> Have had a very quick look at this and whilst I can queue
> my task OK, the runtime then seems to wander off into the
> wild blue yonder and my task doesn't get executed.
>
> Multithreaded debugging - dontcha just love it? Looks like
> its just as much fun under .net as it ever was!
>
> P
>
> >-----Original Message-----
> >The best way IMHO would be to use the
> ThreadPool.QueueUserWorkItem() method,
> >because you don't even have to worry about spawning the
> thread. The syntax
> >is something like:
> >
> >ThreadPool.UnsafeQueueUserWorkItem(
> > new WaitCallback( MyAsyncMethod ), new
> MyAsyncParams( p1, p2,
> >p3 ) );
> >
> >The ThreadPool will execute the method pointed to by the
> WaitCallback
> >delegate and pass it the second parameter. In the example
> above it's using a
> >custom class to wrap several parameters that are passed
> to the method
> >invoked through the delegate.
> >
> >Using the ThreadPool will even save you the extra
> overhead associated with
> >creating a new thread since the delegate is invoked on a
> thread in a thread
> >pool controlled by the .NET Framework, but on the
> downside, you don't have
> >control is you want to pause the running thread for any
> reason.
> >
> >An alternative to QueueUserWorkItem is to invoke a method
> through an
> >asynchronous delegate. This topic is pretty well covered
> in the Framework
> >Documentation under Programming With The .NET Framework-
> >Including
> >Asynchronous Calls [1]. Again, you don't have to worry
> about controlling the
> >threads on which your method executes, because the
> framework runs it in a
> >thread pool thread.
> >
> >HTH,
> >--
> >Christoph Schittko
> >Software Architect
> >
> >[1]
> >http://msdn.microsoft.com/l...
> us/cpguide/html/cpconasynchronousprogramming.asp?frame=true
> >
> >"Peter Hurford" <peter.hurford@microcrest.com> wrote in
> message
> >news:0e8b01c2b69a$8c8747d0$d3f82ecf@TK2MSFTNGXA10...
> >> Have got a C# application and am looking at ways to
> >> improve performance.
> >>
> >> I've found an area of code where there's some work I
> need
> >> to do, but where the user is going to get the same
> >> response regardless of the outcome. Also, this chunk of
> >> work could be quite slow since it involves an http
> >> request/response over the internet.
> >>
> >> Seems like a classic case of spawning this piece of work
> >> in a new thread, and that's what I've attempted to do.
> The
> >> only thing is, I need to pass some parameters into the
> new
> >> thread. It's all quite lightweight - just a couple of
> >> strings.
> >>
> >> I'm new to multithreading under .NET and was wondering
> >> what was the best approach to take? I know there are a
> >> couple of ways to solve this, but which would be the
> best
> >> approach, and why?
> >>
> >> TIA
> >
> >
> >.
> >