Event Driven Code and Thread Control

Brad,

Make it yourself easy.

In Microsoft Windows there is a message pump going around.
Those messages can be catched by your application and then it are the
events.

Most of those events are related to UI operations, but they can be as well
come from other places as disk IO or whatever.

In fact is that is basically all there is.

Cor

"Brad Walton" <ne********@greatergreen.comschreef in bericht
news:uH**************@TK2MSFTNGP06.phx.gbl...

Hello. First post, but been doing a bit of reading here. I am working on a
project in Java, but decided to switch over to C# after seeing some of the
additional features I can get from C#. One of the big changes I want to
make is event-driven code (rather than the linear flow I had in Java). I
have spent a week or so searching Google, talking to a couple of
programming friends, and just chewing on it in my brain. I think I have an
ok handle on delegates (new to me), but I'm still having some issues and
could use some help to push me along in the right direction.

Here is a quick run-down of the program (well, what I had in mind anyway).
There is a GUI thread, a main processing thread (handles parsing, updating
the objects, etc - this could also been on the GUI thread, but not sure if
that is proper design. This would basically be the worker thread where all
the data is actually manipulated), and 2 input threads (1 socket reading
from another application, and 1 file also reading from that same other
application). Both the input threads will be reading data that will affect
the same objects (although most updates will not be of the same
attributes). I'd like for the 2 input threads to fire events at the main
processing thread when they get information. I'd like for that information
to be placed onto the main processing thread when received by it. I'd also
like for this to happen 'instantly' and not use a queue on a timer check
(something I was doing in the Java linear version).

So that's basically where I'm at with it. I have searched Google for c#
info on 'event-driven code', 'delegate marshal thread', etc to try and put
this all together, but I'm not really finding the answers I need. Most of
the marshal information relates to placing it back onto a UI thread (which
could work, but again not sure if that would be good design), not a
specified thread. And this is where I could really use some help. Can I
marshal to a thread I specify? If so, are there any examples, tutorials,
etc?

Any help is greatly appreciated.

Brad

Brad Walton wrote:

Hello. First post, but been doing a bit of reading here. I am working on
a project in Java, but decided to switch over to C# after seeing some of
the additional features I can get from C#. One of the big changes I want
to make is event-driven code (rather than the linear flow I had in
Java). I have spent a week or so searching Google, talking to a couple
of programming friends, and just chewing on it in my brain. I think I
have an ok handle on delegates (new to me), but I'm still having some
issues and could use some help to push me along in the right direction.

Here is a quick run-down of the program (well, what I had in mind
anyway). There is a GUI thread, a main processing thread (handles
parsing, updating the objects, etc - this could also been on the GUI
thread, but not sure if that is proper design. This would basically be
the worker thread where all the data is actually manipulated), and 2
input threads (1 socket reading from another application, and 1 file
also reading from that same other application). Both the input threads
will be reading data that will affect the same objects (although most
updates will not be of the same attributes). I'd like for the 2 input
threads to fire events at the main processing thread when they get
information. I'd like for that information to be placed onto the main
processing thread when received by it. I'd also like for this to happen
'instantly' and not use a queue on a timer check (something I was doing
in the Java linear version).

So that's basically where I'm at with it. I have searched Google for c#
info on 'event-driven code', 'delegate marshal thread', etc to try and
put this all together, but I'm not really finding the answers I need.
Most of the marshal information relates to placing it back onto a UI
thread (which could work, but again not sure if that would be good
design), not a specified thread. And this is where I could really use
some help. Can I marshal to a thread I specify? If so, are there any
examples, tutorials, etc?

Any help is greatly appreciated.

Brad

Look at Control.Invoke. Basically the method allows you to marshal a
delegate to the main GUI thread handling that control, and execute the
method the delegate refers to as part of the GUI thread.

Basically it does this:

1. SendMessage a message to the GUI thread containing the delegate to
execute (SendMessage returns when the message has been processed)
2. The main GUI thread will at some point (depending on how much else it
is doing) process the message, and will thus call the delegate, when it
returns it will put the result into the message record and "return it"
3. The other thread, waiting on SendMessage will resume executing.

This will of course have the effect of serializing all access to the
data structure you're sending data to, and will execute in the GUI
thread. If you're doing lots of heavy painting, the processing of those
messages might take some time to do (relatively speaking).

Another issue is that if you later on decide to separate out the code to
run without a GUI, you're relying on a piece of code that really needs
that message loop.

Personally I would make a class which was thread-safe and could receive
the data without using messages, in a thread-safe manner. If you need to
update a GUI, use a mechanism which simply posts a message to the GUI
thread, and use a thread-safe read/snapshot mechanism to get data from
the intermediate object.

--
Lasse Vågsæther Karlsen
mailto:la***@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3

On Sun, 18 May 2008 01:16:45 -0700, Brad Walton
<ne********@greatergreen.comwrote:

Hello. First post, but been doing a bit of reading here. I am working on
a project in Java, but decided to switch over to C# after seeing some of
the additional features I can get from C#. One of the big changes I want
to make is event-driven code (rather than the linear flow I had in Java).

Lasse provided a good summary of a basic strategy. I'd like to point out
though that Java and .NET/C# don't really differ as much as one might
initially think. Java has EventQueue.invokeAndWait() which is very
similar to Control.Invoke(). It also has thread synchronization
mechanisms very similar to those available in .NET (which would be a
better way to implement a producer/consumer queue than using a timer to
inspect a queue on a regular basis).

Not to dissuade you from moving to .NET...if you don't need the
cross-platform capability of Java, I personally find .NET/C# nicer to work
with (especially inasmuch as C# seems to me to be a language that borrows
the best from Java, while avoiding some of the more clunky aspects). But
I don't think the two are as different as you seem to think.

Finally, to elaborate on what Lasse wrote:

[...]
So that's basically where I'm at with it. I have searched Google for c#
info on 'event-driven code', 'delegate marshal thread', etc to try and
put this all together, but I'm not really finding the answers I need.
Most of the marshal information relates to placing it back onto a UI
thread (which could work, but again not sure if that would be good
design), not a specified thread. And this is where I could really use
some help. Can I marshal to a thread I specify? If so, are there any
examples, tutorials, etc?

You can marshal to a specific thread. See SynchronizationContext for
example. Alternatively, you could have a thread simply monitor a queue of
delegates and consume any delegates you put in the queue. However, most
of the time you don't really need for a specific piece of code to be
executed on a specific thread. That exists in the GUI API because you're
not in control of the processing loop, and the GUI thread has a LOT of
different things it needs to do.

But normally, you'll dedicate a thread to some specific task, and can
better manage that simply by passing data back and forth between threads,
rather than sending a delegate specifically to a thread for execution.
(Besides, even using SynchronizationContext, you need some sort of
dispatch loop...it's no panacea). With thread synchronization objects,
it's very simple to implement a queue that other threads can add data to
and then signal to the thread that's supposed to process the queue to wake
up and start working on the queue.

Pete

----- Original Message -----
From: "Peter Duniho" <Np*********@nnowslpianmk.com>
Newsgroups: microsoft.public.dotnet.languages.csharp
Sent: Sunday, May 18, 2008 4:33 PM
Subject: Re: Event Driven Code and Thread Control

On Sun, 18 May 2008 01:16:45 -0700, Brad Walton
<ne********@greatergreen.comwrote:

>Hello. First post, but been doing a bit of reading here. I am working on
a project in Java, but decided to switch over to C# after seeing some of
the additional features I can get from C#. One of the big changes I want
to make is event-driven code (rather than the linear flow I had in Java).

Lasse provided a good summary of a basic strategy. I'd like to point out
though that Java and .NET/C# don't really differ as much as one might
initially think. Java has EventQueue.invokeAndWait() which is very
similar to Control.Invoke(). It also has thread synchronization
mechanisms very similar to those available in .NET (which would be a
better way to implement a producer/consumer queue than using a timer to
inspect a queue on a regular basis).

Not to dissuade you from moving to .NET...if you don't need the
cross-platform capability of Java, I personally find .NET/C# nicer to work
with (especially inasmuch as C# seems to me to be a language that borrows
the best from Java, while avoiding some of the more clunky aspects). But
I don't think the two are as different as you seem to think.

Yeah, but I just want to learn C# too :-)

You can marshal to a specific thread. See SynchronizationContext for
example. Alternatively, you could have a thread simply monitor a queue of
delegates and consume any delegates you put in the queue. However, most
of the time you don't really need for a specific piece of code to be
executed on a specific thread. That exists in the GUI API because you're
not in control of the processing loop, and the GUI thread has a LOT of
different things it needs to do.

But normally, you'll dedicate a thread to some specific task, and can
better manage that simply by passing data back and forth between threads,
rather than sending a delegate specifically to a thread for execution.
(Besides, even using SynchronizationContext, you need some sort of
dispatch loop...it's no panacea). With thread synchronization objects,
it's very simple to implement a queue that other threads can add data to
and then signal to the thread that's supposed to process the queue to wake
up and start working on the queue.

Pete

Thanks for the replies guys. I appreciate the help. I have continued
searching for better ways to handle this. My design skills in multi-threaded
apps are beginner level (at best). I have played around with the queue
possibility, but I still am running into the same issue. Just to summarize:

I have 3-4 threads (depending on where the 'worker' should go, either on the
main GUI thread or in its own thread). My hang-up is the objects I will be
updating, from both the GUI and possibly a different thread, will read and
write data to/from the objects variables. So I think I am getting into a
synchronization issue with the accessors and any instance variable
manipulation. I have been looking at this as a possible option:
http://en.csharp-online.net/Building...tion_Attribute

I have read good and bad things about this approach. But essentially all
attributes in the classes are readable and writeable, most by seperate
threads (if the 'worker' thread is different from the GUI thread). That is
why I wanted to marshal the info to a specific thread, but if it's not the
GUI thread then it doesn't solve this issue if I marshal it, because the
objects instance variables are still accessible from multiple threads.

So, do I need to sync the entire class for this? Am I thinking about this
properly, or missing the big picture?

Thanks again,
Brad

On Mon, 19 May 2008 19:08:41 -0700, Brad Walton
<ne********@greatergreen.comwrote:

[...]
Thanks for the replies guys. I appreciate the help. I have continued
searching for better ways to handle this. My design skills in
multi-threaded apps are beginner level (at best). I have played around
with the queue possibility, but I still am running into the same issue.

For what it's worth, I would recommend figuring out how multi-threading
works with just two threads as a first step. This is definitely an area
where it's much better to crawl before trying to walk. :)

Just to summarize:

I have 3-4 threads (depending on where the 'worker' should go, either on
the main GUI thread or in its own thread).

You definitely don't want the worker in your GUI thread. The GUI thread
really is only for GUI stuff, and the occasional quick operation (such as
updating values in some class instance that might be used from another
thread :) ).

My hang-up is the objects I will be updating, from both the GUI and
possibly a different thread, will read and write data to/from the
objects variables. So I think I am getting into a synchronization issue
with the accessors and any instance variable manipulation. I have been
looking at this as a possible option:
http://en.csharp-online.net/Building...tion_Attribute

I have read good and bad things about this approach. But essentially all
attributes in the classes are readable and writeable, most by seperate
threads (if the 'worker' thread is different from the GUI thread).

If a given class member is only ever accessed from a given thread, then it
doesn't need to be synchronized at all. Certainly the major downside to
the SynchronizationAttribute is, as the article you referenced says, it's
a pretty broad solution to something that may not need a broad solution.
Locking the entire class just to update one member can definitely
unnecessarily hinder performance.

On the other hand, if you have a class that is used arbitrarily by two or
more threads, and any members can be accessed at any time by any thread,
then maybe the SynchronizationAttribute is a solution for you.

Of course, if that's the case, I'd say there's a good chance there's
something that can be improved about the design. But it really depends on
what you're doing. You haven't offered enough specifics to provide
anything more concrete than that.

That is why I wanted to marshal the info to a specific thread, but if
it's not the GUI thread then it doesn't solve this issue if I marshal
it, because the objects instance variables are still accessible from
multiple threads.

So far, you haven't been specific enough to suggest WHY you might need to
marshal execution of some code onto a different thread.

For GUI work, there's a specific design restriction in the GUI classes
where they insist that when you access all but a handful of members in the
Control class, that access is done on a specific thread. This means you
have to use Invoke() or similar (BeginInvoke(), SynchronizationContext) to
get code that accesses members of a Control instance to run on the thread
than owns that Control.

But otherwise, it's just not a typical situation. It's much more common
to simply need to deal with synchronization by making sure only one thread
is accessing a shared member at a time.

So, do I need to sync the entire class for this? Am I thinking about
this properly, or missing the big picture?

Can't say. We don't know enough about what you're actually doing. For
what it's worth, a concise-but-complete code sample can go a VERY long
way. :)

Pete

Can't say. We don't know enough about what you're actually doing. For

what it's worth, a concise-but-complete code sample can go a VERY long
way. :)

Pete

Here is some additional info. First I made a high-level diagram of the
program: http://www.greatergreen.com/temp/FBDHighLevel.jpg

The blue colored squares represent threads. The green Other Application
represents the app I am connecting to. The Queue is where both input threads
will place new data using a similar design to the one found here (half way
down under More Monitor Methods):
http://www.yoda.arachsys.com/csharp/...eadlocks.shtml

The models are updated from both the Queue (which actually leads to a
parser, then to updating), and the GUI. One other note here, is the parser
piece is where some events are fired off based on certain conditions. I also
will have controller classes to handle many of the model's primary
functions, and to fire off other events if necessary. I want this program to
be as event driven as possible.

The GUI mainly 'gets' info from the models and displays it. It will also set
some things though, which can also be set from the input side.

I also included a typical 'model' class:
http://www.greatergreen.com/temp/Admin.cs

Sorry for the confusion. Please let me know if more info is needed. I wasn't
sure what exactly you weren't clear about, but I will provide any additional
info needed. I'm just trying to get myself going in the right direction
here. This is a learning project for me in C# as well as multithreading. And
I greatly appreciate the help!

Brad

On Tue, 20 May 2008 12:48:23 -0700, Brad Walton
<ne********@greatergreen.comwrote:

>Can't say. We don't know enough about what you're actually doing. For
what it's worth, a concise-but-complete code sample can go a VERY long
way. :)

Here is some additional info. First I made a high-level diagram of the
program: http://www.greatergreen.com/temp/FBDHighLevel.jpg

Unfortunately, that diagram tells us nothing at all about your intended
implementation. It doesn't really offer much additional information
beyond the textual description you provided earlier.

[...]
The models are updated from both the Queue (which actually leads to a
parser, then to updating), and the GUI. One other note here, is the
parser piece is where some events are fired off based on certain
conditions. I also will have controller classes to handle many of the
model's primary functions, and to fire off other events if necessary. I
want this program to be as event driven as possible.

VERY IMPORTANT: when talking about multi-threaded code, it is _critical_
that you be very clear about what kind of "event" you mean when you use
that word. Unfortunately, Microsoft chose to use the same word to
describe a particular language API that is really not a lot different from
simply calling a method directly, as the word that is used to describe a
particular mechanism of inter-thread communication.

In the current context "event-driven" seems to imply the latter, but it's
hard to know for sure. It would be better if you could be explicit about
whether you're talking about C# delegate-based events, or threading
WaitHandle events (e.g. AutoResetEvent and ManualResetEvent).

[...]
Sorry for the confusion. Please let me know if more info is needed. I
wasn't sure what exactly you weren't clear about, but I will provide any
additional info needed. I'm just trying to get myself going in the right
direction here. This is a learning project for me in C# as well as
multithreading. And I greatly appreciate the help!

Well, I will go back to my previous two comments:

1) As a person who is apparently brand-new to multi-threaded
programming, you would probably be better off not tackling this entire
problem all at once. Start with a simpler scenario, in which you have
only two threads, possibly a third represented by your GUI thread. Maybe
put together a simple producer/consumer scenario in which one thread acts
as the producer, another as the consumer. You can combine the GUI thread
with the producer if you like (for example, when the user clicks a button,
that produces one or more things), or you can just create a thread that
continually produces. The consumer thread then would, of course, consume
as well as interact with the GUI thread by using Invoke() to update the UI
as necessary.

Of course, in this sort of implementation, it's not my expectation that
any of the code would do anything useful. Whatever's being "produced" and
"consumed", it's just dummy data. It could be as simple as a plain Object
instance, where any time the consumer sees one, it waits for a fixed
amount of time, or it could be a simple integer that represents the number
of milliseconds the consumer should wait (in either case, the waiting
would represent doing actual work in a real application).

The point is to practice with something that's simpler, so that you can
learn the basic mechanisms first, without being distracted by the need to
get other parts working too.

And...

2) Providing a concise-but-complete code sample is the most
straightforward, most reliable approach to explaining what you mean. The
English language is often a poor way to represent algorithms and code
designs. Code, on the other hand, can do so very precisely. Especially
if you've been specifically asked for code, you should consider very
seriously providing _that_, rather than something else.

For what it's worth, here is a simple producer/consumer implementation I
posted last year:
http://groups.google.com/group/micro...77b0073d421296

It's just the sort of test application I proposed above. It doesn't _do_
anything, but it illustrates the basic mechanics.

There's a lengthy introduction I wrote with it, and it's a complete
console application. It's actually a little more complicated than what's
needed for this discussion, as it supports multiple consumers. The main
console thread acts as the producer. But the default configuration is to
run only a single consumer thread, and so with that you should be able to
start getting a feel for how some of this thread synchronization works.

Pete

VERY IMPORTANT: when talking about multi-threaded code, it is _critical_

that you be very clear about what kind of "event" you mean when you use
that word. Unfortunately, Microsoft chose to use the same word to
describe a particular language API that is really not a lot different from
simply calling a method directly, as the word that is used to describe a
particular mechanism of inter-thread communication.

In the current context "event-driven" seems to imply the latter, but it's
hard to know for sure. It would be better if you could be explicit about
whether you're talking about C# delegate-based events, or threading
WaitHandle events (e.g. AutoResetEvent and ManualResetEvent).

I am referring to delegate based events.

For what it's worth, here is a simple producer/consumer implementation I
posted last year:
http://groups.google.com/group/micro...77b0073d421296

It's just the sort of test application I proposed above. It doesn't _do_
anything, but it illustrates the basic mechanics.

There's a lengthy introduction I wrote with it, and it's a complete
console application. It's actually a little more complicated than what's
needed for this discussion, as it supports multiple consumers. The main
console thread acts as the producer. But the default configuration is to
run only a single consumer thread, and so with that you should be able to
start getting a feel for how some of this thread synchronization works.

Pete

I will have a look at the test application and try to build one myself. I
have spent so much time trying various ideas, that I feel just as confused
now as when I started the porting of this application to C#. Hopefully this
will help clear up some questions.

I appreciate your time Pete. You've been very helpful!

Brad