On Tue, 20 May 2008 12:48:23 -0700, Brad Walton
<newsgroups@greatergreen.comwrote:
Quote:
Quote:
>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.
Quote:
[...]
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).
Quote:
[...]
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
