471,319 Members | 1,211 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

Control.BeginInvoke

I have a question about BeginInvoke method found on the Control class.
To quote the docs:

"Executes the specified delegate asynchronously with the specified
arguments, on the thread that the control's underlying handle was
created on."

Which is fine, but I'm wondering how does this method get called
asynchronously if it's on the same thread we are working on? Surely it
blocks the thread until returned?

Jan 11 '06 #1
9 5489
John,

No, it doesn't. The documentation says that it invokes the method that
the control was created on, not the method that you were working on.

When you call Invoke, the method blocks until the call has been
completed on the UI thread. If you call BeginInvoke, the call is invoked
from the threadpool, and your code can continue asynchronously.

Note, you should not be calling Invoke/BeginInvoke if you are on the
main UI thread. Rather, you should just call the method you want to call.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"john doe" <sl********@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
I have a question about BeginInvoke method found on the Control class.
To quote the docs:

"Executes the specified delegate asynchronously with the specified
arguments, on the thread that the control's underlying handle was
created on."

Which is fine, but I'm wondering how does this method get called
asynchronously if it's on the same thread we are working on? Surely it
blocks the thread until returned?

Jan 11 '06 #2
Nicholas Paldino [.NET/C# MVP] wrote:

<snip>
When you call Invoke, the method blocks until the call has been
completed on the UI thread. If you call BeginInvoke, the call is invoked
from the threadpool, and your code can continue asynchronously.


Do you mean that Control.BeginInvoke(delegate d) is effectively

SomeDelegate x = delegate { Control.Invoke(d); }
x.BeginInvoke();

?

(With *very* rough and ready syntax, of course.)

That seems a horrible way of working - doesn't it mean that with a
fairly busy UI you can easily run out of threadpool threads for tasks
which *wouldn't* block?

Jon

Jan 11 '06 #3
Jon,

No, it can't be what you described, because x.BeginInvoke is not
guaranteed to run on the UI thread. What Control.BeginInvoke is basically a
call to Control.Invoke on a ThreadPool thread. This is very different from
a call to BeginInvoke on the delegate.

And yes, with a fairly busy UI, you could run out of threadpool threads
(if you are updating it constantly from a worker thread with BeginInvoke),
but that's the case with anything that uses the threadpool. That's how the
threadpool is designed. If the task can not be completed on an available
thread, it queues it up, until a thread from the pool is available to
process it.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
Nicholas Paldino [.NET/C# MVP] wrote:

<snip>
When you call Invoke, the method blocks until the call has been
completed on the UI thread. If you call BeginInvoke, the call is invoked
from the threadpool, and your code can continue asynchronously.


Do you mean that Control.BeginInvoke(delegate d) is effectively

SomeDelegate x = delegate { Control.Invoke(d); }
x.BeginInvoke();

?

(With *very* rough and ready syntax, of course.)

That seems a horrible way of working - doesn't it mean that with a
fairly busy UI you can easily run out of threadpool threads for tasks
which *wouldn't* block?

Jon

Jan 11 '06 #4
Nicholas Paldino [.NET/C# MVP] wrote:
No, it can't be what you described, because x.BeginInvoke is not
guaranteed to run on the UI thread.
No, but it wouldn't need to be. Have another look at what I wrote -
it's d that needs to be executed on the UI thread. x is executed on the
thread pool thread (by calling x.BeginInvoke() and that in turn calls
Control.Invoke(d) (obviously using the appropriate control).
What Control.BeginInvoke is basically a call to Control.Invoke on a ThreadPool thread.
That's certainly what I was trying to get across :)
And yes, with a fairly busy UI, you could run out of threadpool threads
(if you are updating it constantly from a worker thread with BeginInvoke),
but that's the case with anything that uses the threadpool. That's how the
threadpool is designed. If the task can not be completed on an available
thread, it queues it up, until a thread from the pool is available to
process it.


It seems unnecessary to use the threadpool for this - it's unclear to
me why this can't just be put on the list of messages for the UI to
process. Ah well. Just another reason not to use the system
threadpool... I must update my threading pages to explain threadpool
deadlock at some stage (not that it's relevant here, I believe).

Jon

Jan 11 '06 #5
Actually, you are right, it does something like this (it creates its own
queue, not of threads, but of calls).

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
Nicholas Paldino [.NET/C# MVP] wrote:
No, it can't be what you described, because x.BeginInvoke is not
guaranteed to run on the UI thread.


No, but it wouldn't need to be. Have another look at what I wrote -
it's d that needs to be executed on the UI thread. x is executed on the
thread pool thread (by calling x.BeginInvoke() and that in turn calls
Control.Invoke(d) (obviously using the appropriate control).
What Control.BeginInvoke is basically a call to Control.Invoke on a
ThreadPool thread.


That's certainly what I was trying to get across :)
And yes, with a fairly busy UI, you could run out of threadpool
threads
(if you are updating it constantly from a worker thread with
BeginInvoke),
but that's the case with anything that uses the threadpool. That's how
the
threadpool is designed. If the task can not be completed on an available
thread, it queues it up, until a thread from the pool is available to
process it.


It seems unnecessary to use the threadpool for this - it's unclear to
me why this can't just be put on the list of messages for the UI to
process. Ah well. Just another reason not to use the system
threadpool... I must update my threading pages to explain threadpool
deadlock at some stage (not that it's relevant here, I believe).

Jon

Jan 11 '06 #6
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
Actually, you are right, it does something like this (it creates its own
queue, not of threads, but of calls).


So it doesn't need the thread pool? Hmm... I can see I'm going to have
to investigate this :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 11 '06 #7
I've just read this article:
http://www.codeproject.com/csharp/begininvoke.asp which at the bottom
says

"Control.BeginInvoke does not use a threadpool thread, it does a
PostMessage to the target window handle and returns."

Who is right? Personally I know who I trust more, but I'd like to know
how the information both you and the author of the article above have
go this extra information from.

Jan 12 '06 #8
john doe wrote:
I've just read this article:
http://www.codeproject.com/csharp/begininvoke.asp which at the bottom
says

"Control.BeginInvoke does not use a threadpool thread, it does a
PostMessage to the target window handle and returns."

Who is right? Personally I know who I trust more, but I'd like to know
how the information both you and the author of the article above have
go this extra information from.


There's a fairly easy way to find out, fortunately. Here's some code
which does the following:

1) Makes sure that the ThreadPool has created all the threads it can
use
2) Jams up the ThreadPool with jobs which just sleep and indicate when
they're done
3) Checks there are no available threads
4) Creates a form
5) Starts a new background task (see 7)
6) Runs the form
7) After sleeping, the background task calls BeginInvoke on the form
with a delegate
8) The delegate indicates when it's done

Running it, the delegate used as an argument to BeginInvoke gets called
even though the ThreadPool has no available threads. This suggests that
the ThreadPool isn't involved.

Of course, I'm happy to be told why my test is broken :)

Jon
using System;
using System.Windows.Forms;
using System.Threading;

class Test
{
static Form f;

static void Main()
{
// Crank the thread-pool up to have all its threads running
int threads, ioc, ignored;
ThreadPool.GetMinThreads(out ignored, out ioc);
ThreadPool.GetMaxThreads(out threads, out ignored);
ThreadPool.SetMinThreads(threads, ioc);

// Jam up the threadpool
for (int i=0; i < 100; i++)
{
ThreadPool.QueueUserWorkItem(new
WaitCallback(SleepWorkItem), i);
}
// Let them all get scheduled
Thread.Sleep(500);

ThreadPool.GetAvailableThreads(out threads, out ignored);
Console.WriteLine ("Number of available ThreadPool threads:
{0}", threads);

f = new Form();

new Thread (new ThreadStart(BackgroundThread)).Start();

Application.Run(f);
}

static void BackgroundThread()
{
// Wait for the form to be shown
Thread.Sleep (1000);
f.BeginInvoke (new EventHandler(RunInUIThread));
Console.WriteLine ("BackgroundThread finishing");
}

static void RunInUIThread(object sender, EventArgs e)
{
Console.WriteLine ("RunInUIThread executing");
}

static void SleepWorkItem(object state)
{
// Wait a long time
Thread.Sleep(5000);
Console.WriteLine ("Sleep item {0} finishing", state);
}
}

Jan 12 '06 #9

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
| Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
| > Actually, you are right, it does something like this (it creates its
own
| > queue, not of threads, but of calls).
|
| So it doesn't need the thread pool? Hmm... I can see I'm going to have
| to investigate this :)
|
| --
| Jon Skeet - <sk***@pobox.com>
| http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
| If replying to the group, please do not mail me too

None of the Invoke or BeginInvoke are actually using the ThreadPool. Both
directly call the method (and wait for return) when running on the UI
thread, else the delegate (and some more stuff like the execution context)
is queue'd in a private queue and a private user message is posted to the
windows queue. The window procedure responsible for handling the private
message picks up the item from the queue and executes the delegate target.
The difference between Invoke and BeginInvoke is that the first wait for the
message to be handled by the message handler, while the latter returns after
the message has been posted.
Willy.


Jan 12 '06 #10

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Grandma Wilkerson | last post: by
2 posts views Thread by Ingo Schasiepen | last post: by
9 posts views Thread by David Sworder | last post: by
6 posts views Thread by Valerie Hough | last post: by
7 posts views Thread by Ben Voigt [C++ MVP] | last post: by
3 posts views Thread by Steve | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.