Rising events between threads

You can not inject a call into the call stack of another thread without
that thread doing something to be notified of the incoming call. This is
why you can have delegates called on a UI thread. Because the UI thread has
a message pump that cycles in a loop, you can inject something to be
processed into that loop, in this case, your delegate call.

For other threads, you pretty much have to do the same thing, that is,
have a loop waiting for a signal to execute your delegate.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Gotch@" <da******@gmail .comwrote in message
news:11******** **************@ n2g2000hse.goog legroups.com...

Hi all,

I've recently digged into C# and the whole .Net stuff. Particularly I
found the idea of adding Events and Delegates to the C# language very
interesting and I'm trying to use them in every weird way that comes
to my mind. Particularly I'm struggling to find a way to use events
between threads.

In particular I'd like to know how to rise and event from a thread and
have it received from the delegate in another thread (I mean the other
thread wakes up and executes the delegate)... And going over... is it
possible to broadcast events? Or, even better, to decide the
destination thread?

I remember that in the past there where messages in windows, not
events, and you could send them through threads safely. But they were
a different thing cos, I think, delegates are just function pointers
and events are bundles of them (ok, with some extras maybe)...

So is it possible to do this with events? Or are there other ways,
similarly easy and convenient (I'm not taling about Monitor, Mutex and
co... I know them...)?

Thanks in advance. Bye.

Thanks,
and my question is... How do I do that?
On 3 Lug, 17:32, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

You can not inject a call into the call stack of another thread without
that thread doing something to be notified of the incoming call. This is
why you can have delegates called on a UI thread. Because the UI thread has
a message pump that cycles in a loop, you can inject something to be
processed into that loop, in this case, your delegate call.

For other threads, you pretty much have to do the same thing, that is,
have a loop waiting for a signal to execute your delegate.

--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard .caspershouse.c om

"Gotch@" <dario...@gmail .comwrote in message

news:11******** **************@ n2g2000hse.goog legroups.com...

Hi all,

I've recently digged into C# and the whole .Net stuff. Particularly I
found the idea of adding Events and Delegates to the C# language very
interesting and I'm trying to use them in every weird way that comes
to my mind. Particularly I'm struggling to find a way to use events
between threads.

In particular I'd like to know how to rise and event from a thread and
have it received from the delegate in another thread (I mean the other
thread wakes up and executes the delegate)... And going over... is it
possible to broadcast events? Or, even better, to decide the
destination thread?

I remember that in the past there where messages in windows, not
events, and you could send them through threads safely. But they were
a different thing cos, I think, delegates are just function pointers
and events are bundles of them (ok, with some extras maybe)...

So is it possible to do this with events? Or are there other ways,
similarly easy and convenient (I'm not taling about Monitor, Mutex and
co... I know them...)?

Thanks in advance. Bye.

Just like I told you, you basically have to have a loop in your thread
which will process messages/notifications which are set on other threads.
You can use windows messages, some sort of queue structure, etc, etc. It's
a basic producer/consumer pattern.

Is there a particular reason why you want to have one single thread
process delegates? What exactly are you trying to do?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Gotch@" <da******@gmail .comwrote in message
news:11******** **************@ m36g2000hse.goo glegroups.com.. .

Thanks,
and my question is... How do I do that?
On 3 Lug, 17:32, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

> You can not inject a call into the call stack of another thread
without
that thread doing something to be notified of the incoming call. This is
why you can have delegates called on a UI thread. Because the UI thread
has
a message pump that cycles in a loop, you can inject something to be
processed into that loop, in this case, your delegate call.

For other threads, you pretty much have to do the same thing, that
is,
have a loop waiting for a signal to execute your delegate.

--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard .caspershouse.c om

"Gotch@" <dario...@gmail .comwrote in message

news:11******* *************** @n2g2000hse.goo glegroups.com.. .

Hi all,

I've recently digged into C# and the whole .Net stuff. Particularly I
found the idea of adding Events and Delegates to the C# language very
interesting and I'm trying to use them in every weird way that comes
to my mind. Particularly I'm struggling to find a way to use events
between threads.

In particular I'd like to know how to rise and event from a thread and
have it received from the delegate in another thread (I mean the other
thread wakes up and executes the delegate)... And going over... is it
possible to broadcast events? Or, even better, to decide the
destination thread?

I remember that in the past there where messages in windows, not
events, and you could send them through threads safely. But they were
a different thing cos, I think, delegates are just function pointers
and events are bundles of them (ok, with some extras maybe)...

So is it possible to do this with events? Or are there other ways,
similarly easy and convenient (I'm not taling about Monitor, Mutex and
co... I know them...)?

Thanks in advance. Bye.

It looks like what you want is System.Threadin g.ThreadPool. It keeps
a bunch of threads on standby and wakes them up to process delegates
for you. If you want a dedicated thread look at
System.Componen tModel.Backgrou ndWorker

On Tue, 03 Jul 2007 08:34:14 -0700, Gotch@ <da******@gmail .comwrote:

On 3 Lug, 17:32, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

>[...] Because the UI thread has
a message pump that cycles in a loop, you can inject something to be
processed into that loop, in this case, your delegate call.

For other threads, you pretty much have to do the same thing, that
is,
have a loop waiting for a signal to execute your delegate.

Thanks,
and my question is... How do I do that?

There are two obvious ways, depending on what the nature of the threads
are.

To pass a delegate to a UI thread, all you need to do is call Invoke() or
BeginInvoke() on a Control instance owned by that thread. Typically, this
would be the main form for the application.

To pass a delegate to a non-UI thread, you need to implement your own
version of an event/message queue that can deal with handling delegates.
And of course, the simplest version of that would be to simply have a
queue of delegates (e.g. "Queue<Delegate >"). If the delegate must always
conform to a specific signature, then use the specific delegate type
instead of "Delegate". If not, then you'll probably want to allow the
inclusion of an array of objects to pass as parameters as well (e.g. make
a struct that contains references to both a delegate instance and an
object[], and put that in your queue).

Keep in mind that you of course will want to synchronize access to the
queue, and you will want the processing thread (the one pulling things
from the queue to execute) to wait until some other thread has signaled
it. See the AutoResetEvent class and "lock()" statement for how to do
that.

Pete

On Tue, 03 Jul 2007 09:01:31 -0700, james <ja********@gma il.comwrote:

It looks like what you want is System.Threadin g.ThreadPool. It keeps
a bunch of threads on standby and wakes them up to process delegates
for you. If you want a dedicated thread look at
System.Componen tModel.Backgrou ndWorker

I don't think that's what he wants. It sounds as though he wants a
delegate to be run on a specific thread, not some arbitrary thread pulled
from the thread pool.

I could be wrong, but that's my reading of the thread so far.

Pete

Peter Duniho wrote:

On Tue, 03 Jul 2007 09:01:31 -0700, james <ja********@gma il.comwrote:

>It looks like what you want is System.Threadin g.ThreadPool. It keeps
a bunch of threads on standby and wakes them up to process delegates
for you. If you want a dedicated thread look at
System.Compone ntModel.Backgro undWorker

I don't think that's what he wants. It sounds as though he wants a
delegate to be run on a specific thread, not some arbitrary thread pulled
from the thread pool.

I could be wrong, but that's my reading of the thread so far.

Pete

Hi Pete,

I could be wrong, but that's my reading of the thread so far.

<big grin>

--
Tom Spink
University of Edinburgh

Gotch@ wrote:

Thanks,
and my question is... How do I do that?
On 3 Lug, 17:32, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guar d.caspershouse. comwrote:

> You can not inject a call into the call stack of another thread
without
that thread doing something to be notified of the incoming call. This is
why you can have delegates called on a UI thread. Because the UI thread
has a message pump that cycles in a loop, you can inject something to be
processed into that loop, in this case, your delegate call.

For other threads, you pretty much have to do the same thing, that
is,
have a loop waiting for a signal to execute your delegate.

--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard .caspershouse.c om

"Gotch@" <dario...@gmail .comwrote in message

news:11******* *************** @n2g2000hse.goo glegroups.com.. .

Hi all,

I've recently digged into C# and the whole .Net stuff. Particularly I
found the idea of adding Events and Delegates to the C# language very
interesting and I'm trying to use them in every weird way that comes
to my mind. Particularly I'm struggling to find a way to use events
between threads.

In particular I'd like to know how to rise and event from a thread and
have it received from the delegate in another thread (I mean the other
thread wakes up and executes the delegate)... And going over... is it
possible to broadcast events? Or, even better, to decide the
destination thread?

I remember that in the past there where messages in windows, not
events, and you could send them through threads safely. But they were
a different thing cos, I think, delegates are just function pointers
and events are bundles of them (ok, with some extras maybe)...

So is it possible to do this with events? Or are there other ways,
similarly easy and convenient (I'm not taling about Monitor, Mutex and
co... I know them...)?

Thanks in advance. Bye.

Hi,

I'm glad you're getting into C#. It is pretty superb.

Because what you said sounds really cool, I've whipped up a quick example of
executing a delegate on another thread, and I've made it deliberately
extensible to show that it uses a message-passing design pattern.

It would be rude to post it here, because it's a bit big, so please take a
look at it here:

http://www.betasafe.com/code?view=deleginv

--
Tom Spink
University of Edinburgh

On Tue, 03 Jul 2007 10:14:00 -0700, Tom Spink <ts****@gmail.c omwrote:

[...]
It would be rude to post it here, because it's a bit big, so please take
a
look at it here:

http://www.betasafe.com/code?view=deleginv

IMHO, it's rude _not_ to post the code here. Well, okay...maybe not so
much "rude" as "short-sighted".

This newsgroup is likely to be archived for some arbitrarily long period
of time. Who knows how long, but the current archives (the largest
repository I know of is now maintained by Google) go back decades. When
you post a link to a web site instead copying the code into the post
itself, you limit the lifetime of the usefulness of your post to that of
your web site. The message itself may live on longer than that (and it
probably will), but it won't be of any use to anyone else at that point.

When will your web site go defunct? One hopes not for a long time, but it
could be tomorrow, next month, next year, whatever. Whatever the
lifetime, it's too short as compared to the likely lifetime of the
newsgroup.

More importantly, if you include the code in your post, the lifetime of
that copy of the code is tied perfectly to the newsgroup, which is exactly
what one wants. Your article's lifetime should match the newsgroup's
lifetime, whether shorter or longer than your web site's, rather than
matching that of your web site.

Besides, while the code might be long, it's certainly no longer than the
huge number of top-posted, untrimmed articles other people post to the
newsgroup every day. I'm not saying two wrongs make a right, but in this
case I don't think it would be wrong to post the code, and in fact is
beneficial, and at the very least would help improve the signal-to-noise
ratio here (admittedly, already better than is found in many other
newsgroups, but still...)

Pete