Calling a function with in a thread

[Pubs]

Hi all,

I want to call a function with some intial parameters with in a
thread. At the end of the function execution it should return a value
to the caller. Caller is outside the thread.

Example


function test (int a, int b);
{
int y = a=b;
return y;
}

how can i call this function and get the return ?

Thank you,
Pubduu

 

[Jon Skeet [C# MVP]]

I want to call a function with some intial parameters with in a
thread. At the end of the function execution it should return a value
to the caller. Caller is outside the thread.

So what is the caller's thread doing at the time? Does it provide some
way to marshall calls back onto it (as, say, the UI threads in WinForms
and WPF both do)?

 

[Pubs]

So what is the caller's thread doing at the time? Does it provide some
way to marshall calls back onto it (as, say, the UI threads in WinForms
and WPF both do)?

--
Jon Skeet - <[email protected]>
Web site:http://www.pobox.com/~skeet 
Blog:http://www.msmvps.com/jon.skeet
C# in Depth:http://csharpindepth.com

I am calling my function from the UI. Button press can call that
function. Function should be inside a thread since I dont want to lock
the interface until it is finished. But at the end of the function it
should return the value back to the button.

 

[Sujeet]

Thread constructor has an overload that takes ParameterizedThreadStart
delegate as one of its parameter. You can use that to pass an object from the
caller
The best way to return some value back to the caller is to set some value on
the passed Object.

Hope it helps.

Sujeet

 

[Pubs]

Thread constructor has an overload that takes ParameterizedThreadStart
delegate as one of its parameter. You can use that to pass an object from the
caller
The best way to return some value back to the caller is to set some value on
the passed Object.

Hope it helps.

Sujeet






- Show quoted text -

Could u please show me some code or any tutorial ? I am still a
bigginer.

Pubudu

 

[Pubs]

The "best way"?  I disagree.  In fact, that's likely to be the absolute  
worst way, unless you combine with some sort of event-driven inter-thread  
communication as well.  Otherwise, the other thread can only detect the  
completion by polling the value being set.

As far as the original question goes:

Based on the problem description so far, I think that the BackgroundWorker 
class is probably your best bet.  Subscribe to the DoWork and  
RunWorkerCompleted events, and the delegate method subscribed to each  
event will be run on the correct thread: the DoWork handler will be run on 
a background thread, and the RunWorkerCompleted handler will be run on the 
original thread (the GUI thread in this case).

That is probably sufficient advice, but if you decide that for some reason 
the BackgroundWorker class isn't appropriate, here are some other details  
(note that the BackgroundWorker class is a special case of all of the  
following, fully encapsulating the techniques described as part of the  
basic functionality of the BackgroundWorker class)...

The best way to deal with the "thread complete" scenario is to call a  
method.  If the code executing in the thread is part of the same class  
that starts the thread (for example, a Form sub-class), then you can just  
call some specific method within the class.  Otherwise, it would probably  
make more sense for the class containing the thread code to allow for the  
calling class to provide a delegate to be called with the thread code  
completes.

The usual way to do this latter approach is to declare an event on the  
thread class, have the client subscribe to the event, and then raise the  
event when the thread is done.  An alternative would be, for example, to 
simply allow the caller to pass a delegate directly, and then invoke the  
delegate when the thread is done (this is basically what an event does  
anyway, but in a more flexible, general-purpose way).

Now, to get the "completed" code to execute on a specific thread, you need 
some way to marshal the execution onto that specific thread.  Since you  
are apparently trying to get back onto your main GUI thread, the most  
appropriate mechanism for doing this would be to use the Control.Invoke()  
method.  If the thread code is already fully "aware of" the GUI code (e.g.  
it's actually part of the Form sub-class), then you might as well just  
call Invoke() from within the thread code.  Otherwise, it will probably  
make more sense to have the thread call some specific method in the client 
class (via the mechanisms described above), and let that method deal with  
calling Invoke() on the appropriate instance.

As far as sample code goes, use Google or MSDN search to look for specific 
topics on the use of BackgroundWorker, Control.Invoke() and the C# "event" 
keyword.  There is no shortage of existing examples in MSDN, this  
newsgroup, and a variety of other web sites.

Pete

Thank you for the recommandations. I did not know about the DoWork. I
think that is appropriate for me.

Pubudu

 

[Sujeet]

Peter,
Yes I agree that this is not the best way considering a more uber level;
maybe I mistyped. I was just trying to get to the most trivial solution.
BackgroundWorker should do the trick and so will a delegate that you can
call asynchronously.
But I think Pubs for your case BackgroundWorker fits right.

Sujeet

 

[Marc Gravell]

(agree that BackgroundWorker is a easy way to get this done...)

Re ParameterizedThreadStart - my main gripe with this is that it only
allows one arg, and there is no compile-time safety.

I would much rather use an anon-method to do this (obviously you can
move as-much or as-little out to separate methods if it gets big...):

void SomeEventHandler(object sender, EventArgs args)
{
// here running on UI thread
ThreadPool.QueueUserWorkItem(delegate
{
// here running on pool thread
int i = SomeFunction("foo", "bar");
this.Invoke((MethodInvoker)delegate
{
// here running as callback on UI thread
this.Text = i.ToString();
});
});
}

Marc