Click to See Complete Forum and Search --> : messages and C++


superbonzo
March 24th, 2009, 05:19 AM
In my multithreaded projects I mainly use locks (eg critical sections), interlocked primitives and messages as means of synchronization; The first two can be easily and effectively wrapped in C++ facilities; The problem arises when I have to deal with a message system and its proper/general encapsulation in a C++ hierarchy (specifically, I'm mainly interested in windows development, and I'm using message-only-windows to write lightweight "GUI-thread" (eg. a thread with message pump) with custom messages, but I'm not necessarily restricted to this message system per se).
Now, given that a message has "fixed type" nature, in the sense that the content of a message is fixed by the message system (for example, windows can post (UINT,LPARAM,WPARAM) triples only ) what's your approach to message-based C++ multithreaded programming ?
I have selected some possibilities:

1- simple messages: messages are restricted in type and serves as a basic comunication mechanism only; bool, int and other small types are posted.
2- simple messages with polymorphism: messages are simple or carry a pointer to a polymorphic base type; if the post is asynchronous the pointed-to object is in the heap and must be freed by the reciever of the message;
3- as above, but 'new' is overloaded to garbage collect messages data in a per-thread basis
4- full encapsulation: messages are hidden behind a C++ facility; ie. posting a message is indistinguishable from calling a method (with synchronous/asynchronous semantics); here, you have 'to get dirty' with templates and (well hidden) C++ casts to have a general messaging scheme.
5- you write your own message pump with a built-in project-oriented class hierarchy (ie. the types supported for messaging are the only types you need to post )

Thank you!

Lindley
March 24th, 2009, 06:48 PM
The only time I've written a multithreaded GUI, I simply relegated one thread to GUI handling exclusively, and used mutex locks to allow other threads to interact with the data it drew on.

superbonzo
March 24th, 2009, 08:07 PM
well, I'm not specifically thinking to GUI development ( if you are referring to the line im my post where I speak about "GUI-threads" I meant simply a thread with a message pump ( maybe it's not a standard terminology but it's used on MSDN ) ).

So, have you ever coded a multithreaded application based on a messaging system between threads ? if yes, what class design have you used (see points 1-5 in my post) ?