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