Calling a function with in a thread

Pubs <pu******@gmail.comwrote:

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)?

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

On Jun 11, 6:54*pm, Jon Skeet [C# MVP] <sk...@pobox.comwrote:

Pubs <pubud...@gmail.comwrote:

* *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)?

--
Jon Skeet - <sk...@pobox.com>
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.

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" wrote:

On Jun 11, 6:54 pm, Jon Skeet [C# MVP] <sk...@pobox.comwrote:

Pubs <pubud...@gmail.comwrote:

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)?

--
Jon Skeet - <sk...@pobox.com>
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.

On Jun 11, 8:07*pm, Sujeet <Suj...@discussions.microsoft.comwrote:

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" wrote:

On Jun 11, 6:54 pm, Jon Skeet [C# MVP] <sk...@pobox.comwrote:

Pubs <pubud...@gmail.comwrote:
* *I want to call a function with some intial parameters with ina
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)?

--
Jon Skeet - <sk...@pobox.com>
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.- Hide quoted text -

- Show quoted text -

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

Pubudu

On Wed, 11 Jun 2008 17:07:00 -0700, Sujeet
<Su****@discussions.microsoft.comwrote:

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.

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

On Jun 11, 8:41*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:

On Wed, 11 Jun 2008 17:07:00 -0700, Sujeet *

<Suj...@discussions.microsoft.comwrote:

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.

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

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
"Pubs" wrote:

On Jun 11, 8:41 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:

On Wed, 11 Jun 2008 17:07:00 -0700, Sujeet

<Suj...@discussions.microsoft.comwrote:

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.

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

(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

On Thu, 12 Jun 2008 00:25:31 -0700, Marc Gravell <ma**********@gmail.com
wrote:

(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.

Well, you could always pass an array of objects. Still no type safety,
but beggars can't be choosers. :)

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...):

And the example you posted (not that there's anything wrong with it, as
far as it goes) works fine with BackgroundWorker too:

BackgroundWorker bw = new BackgroundWorker();
int i;

bw.DoWork += delegate { i = SomeFunction("foo", "bar"); };
bw.RunWorkerCompleted += delegate { this.Text = i.ToString(); };

That's assuming I understand my variable capturing rules correctly, and
"i" is the same variable in both delegate methods. Someone check my
work. :)

Pete