Control.BeginInvoke

J

john doe

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

Nicholas Paldino [.NET/C# MVP]

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

Jon Skeet [C# MVP]

Nicholas Paldino [.NET/C# MVP] wrote:

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
 
N

Nicholas Paldino [.NET/C# MVP]

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]
- (e-mail address removed)

Jon Skeet said:
Nicholas Paldino [.NET/C# MVP] wrote:

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
 
J

Jon Skeet [C# MVP]

Nicholas said:
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
 
N

Nicholas Paldino [.NET/C# MVP]

Actually, you are right, it does something like this (it creates its own
queue, not of threads, but of calls).
 
J

Jon Skeet [C# MVP]

Nicholas Paldino said:
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 :)
 
J

john doe

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

Jon Skeet [C# MVP]

john said:
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);
}
}
 
W

Willy Denoyette [MVP]

| > 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 - <[email protected]>
| 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top