Control.BeginIn voke

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

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

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

"john doe" <sl********@gma il.com> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.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?

[Jon Skeet [C# MVP]]

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.BeginIn voke(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]]

Jon,

No, it can't be what you described, because x.BeginInvoke is not
guaranteed to run on the UI thread. What Control.BeginIn voke 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.co m

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.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.BeginIn voke(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 Skeet [C# MVP]]

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.BeginIn voke 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]]

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.co m

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:11******** *************@g 14g2000cwa.goog legroups.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.BeginIn voke 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

[Jon Skeet [C# MVP]]

Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard .caspershouse.c om> 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.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[john doe]

I've just read this article:
http://www.codeproject.com/csharp/begininvoke.asp which at the bottom
says

"Control.BeginI nvoke 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.

[Jon Skeet [C# MVP]]

john doe wrote:

I've just read this article:
http://www.codeproject.com/csharp/begininvoke.asp which at the bottom
says

"Control.BeginI nvoke 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.Threadin g;

class Test
{
static Form f;

static void Main()
{
// Crank the thread-pool up to have all its threads running
int threads, ioc, ignored;
ThreadPool.GetM inThreads(out ignored, out ioc);
ThreadPool.GetM axThreads(out threads, out ignored);
ThreadPool.SetM inThreads(threa ds, ioc);

// Jam up the threadpool
for (int i=0; i < 100; i++)
{
ThreadPool.Queu eUserWorkItem(n ew
WaitCallback(Sl eepWorkItem), i);
}
// Let them all get scheduled
Thread.Sleep(50 0);

ThreadPool.GetA vailableThreads (out threads, out ignored);
Console.WriteLi ne ("Number of available ThreadPool threads:
{0}", threads);

f = new Form();

new Thread (new ThreadStart(Bac kgroundThread)) .Start();

Application.Run (f);
}

static void BackgroundThrea d()
{
// Wait for the form to be shown
Thread.Sleep (1000);
f.BeginInvoke (new EventHandler(Ru nInUIThread));
Console.WriteLi ne ("BackgroundThr ead finishing");
}

static void RunInUIThread(o bject sender, EventArgs e)
{
Console.WriteLi ne ("RunInUIThr ead executing");
}

static void SleepWorkItem(o bject state)
{
// Wait a long time
Thread.Sleep(50 00);
Console.WriteLi ne ("Sleep item {0} finishing", state);
}
}

[Willy Denoyette [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...
| Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard .caspershouse.c om> 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.co m>
| 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.