Re: Creating a C++ like message loop in .NET threaded classes.
- From: Nate A <NateA@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 29 Apr 2005 14:16:04 -0700
Thanks Dmytro, I ended up taking your suggestion, but instead of using the
API functions I wrote a base class that starts a thread in its constructor
that essentially goes through an inifite loop of processing "messages" that
are posted by external code to it's "queue" and blocking the thread with a
ManualResetEvent object when there are no messages to process (and waking the
thread back up when a message is posted). This seems to work very well.
"Dmytro Lapshyn [MVP]" wrote:
> Hi Nate,
>
> Just grab your good ol' C++ message loop knowledge and write the same code
> in .NET, calling API functions such as GetMessage and DispatchMessage
> through P/Invoke. A colleague of mine did just that a week ago and it works
> like a charm. Just be sure to declare your own MSG structure, do not use the
> System.Windows.Forms.Message one - proven to be buggy for this purposes.
>
> --
> Sincerely,
> Dmytro Lapshyn [Visual Developer - Visual C# MVP]
>
>
> "Nate A" <NateA@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:28FABF18-D834-4A4D-B181-1DE89D54797B@xxxxxxxxxxxxxxxx
> > .NET is certainly the best thing to happen to RAD since the invention of
> > high-level languages. The one thing I miss from the world of C++ however,
> > is
> > control over Windows message processing (or maybe it's in the .NET and I
> > don't know about it, that's kinda what this post is about.)
> >
> > .NET forms and its controls nicely wrap system messages like keyboard and
> > mouse actions and link them to events that run on the threads of those
> > "Windowed" components like you'd expect in a C++ MFC application, without
> > all
> > the dirty work of writing the message handling macros in MFC.
> >
> > However, when you go beyond the behind-the-scenes threads that each
> > "windowed" object intrinsically creates, and want to write a non-gui type
> > class that processes custom messages on its own thread, I'm surprised to
> > find
> > that the .NET framework apparently does not contain any classes to do this
> > (as far as I can tell.) I first investigated the System.Messaging
> > namespace
> > assuming I'd find what I'm looking for in there, but apparently that
> > namespace deals with sending messages between separate process and even
> > machine boundaries and is not what I’m looking for.
> >
> > I typically find the need for this kind of message processing when I'm
> > writing a singleton class that, at run time, will have its members invoked
> > by
> > other parts of the application from other threads in a more or less
> > unpredictable manner. Now I don't necessarily want the code of these
> > members
> > to be executed on the calling thread and block that thread until the
> > member
> > has completed executing, all I want is for the calling thread to "post a
> > message" to my threaded singleton class, return immediately, and continue
> > on
> > its own business, and have the singleton class's own thread process these
> > messages in the order they came in. So basically this is exactly how a MFC
> > windowed object processes messages---a message is sent to the object from
> > anywhere and any thread, the object processes the message when its thread
> > is
> > free to do so, and when there are no more messages to process, the thread
> > sleeps until it is woken up by a new message.
> >
> > Without this functionality, I've found that some of my classes that are
> > being invoked often and by a variety of other threads are causing a
> > race-condition of 2 or more threads and bringing CPU usage up to 100% even
> > when my app is doing almost nothing. I of course have to "SyncLock" most
> > of
> > the members to avoid collisions, but I'm having a hell of a time debugging
> > the code because it seems that every once in a while 2 or more threads
> > will
> > end up in a race-condition waiting for their chance to SyncLock the
> > resource
> > and blocking indefinitely. This could all be fixed by using the message
> > loop
> > type construct i was talking about, thereby allowing me to know that the
> > only
> > thread modifying data in the class will be the classe's own
> > thread---making
> > critical sections on member data unnecessary and race conditions unlikely
> > if
> > not impossible.
> >
> > Does anyone know of a .NET class that handles what I'm talking about? Or
> > is
> > it possible this is not even necessary and there should be a better
> > muti-threaded approach I should take? I must admit that I am fairly new to
> > writing programs that have more than two simultaneous threads and concede
> > that there may be something fundamentally wrong with my understanding of
> > threading and thread synchronization.
> >
> > Any help would be greately appreciated.
> >
> > -Nate A
> >
>
>
.
- References:
- Creating a C++ like message loop in .NET threaded classes.
- From: Nate A
- Re: Creating a C++ like message loop in .NET threaded classes.
- From: Dmytro Lapshyn [MVP]
- Creating a C++ like message loop in .NET threaded classes.
- Prev by Date: RE: async calls
- Next by Date: Re: How can i FTP with SSL or TLS encryption?
- Previous by thread: Re: Creating a C++ like message loop in .NET threaded classes.
- Next by thread: String.Lenght vs String.Empty
- Index(es):
Relevant Pages
|
Loading
