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

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" <(E-Mail Removed)> wrote in message
news:28FABF18-D834-4A4D-B181-(E-Mail Removed)...
> .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
>

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" <(E-Mail Removed)> wrote in message
> news:28FABF18-D834-4A4D-B181-(E-Mail Removed)...
> > .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
> >
>
>

If the only purpose of the thread is to process Windows messages, you don't
need an event. The GetMessage API call will block the thread until there's
something in the message queue.

If you however set up your own queue and processing logic (like a queue of
work items), consider using the ThreadPool class.

--
Sincerely,
Dmytro Lapshyn [Visual Developer - Visual C# MVP]


"Nate A" <(E-Mail Removed)> wrote in message
news:109583D0-CB84-44AE-876A-(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
>> news:28FABF18-D834-4A4D-B181-(E-Mail Removed)...
>> > .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
>> >
>>
>>