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?

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]
- (E-Mail Removed)

"john doe" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>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?
>

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

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

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

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

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]
- (E-Mail Removed)

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

Nicholas Paldino [.NET/C# MVP] <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

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.

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);
}
}

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
| Nicholas Paldino [.NET/C# MVP] <(E-Mail Removed)> 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 - <(E-Mail Removed)>
| 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.