Re: Multitasking in C++...
werasm wrote:
I have a (possibly) very naive question:
Good question IMO.
Most of the software that we write consist of an architecture where
multiple tasks/threads wait/block at a MsgQ (or Mailbox) until the next
message arrives.
The messages can only be commands (GOF command). A command can be
associated with a "CommandServer", in which case it executes in the
context (thread) of the CommandServer (the context in which the MsgQ
associated with that server is serviced).
Why not have multiple mq's then? In which case you wouldn't need to
stuff the command with a reference to the command server (a worker
thread, I guess?) and mitigate possible contention between command
servers extracting commands from the same queue.
MsgQ's are of course Thread
Safe devices, and when implemented (if not provided by the API), they
consist of a normal queue. Access to queue are protected by mutual
exclusion), and notification to unblock the recipient are performed by
Counting Semaphore.
If your queue data structure probably provides something like
std::queue<>::empty() you may not care about losing notifications when
a new command added to the queue while no command server is waiting for
the notification; one would just check if the queue is empty before
blocking to wait for a notification. I wonder why you need a counting
semaphore, rather than a mutex + condition.
Posting over queues are always non-blocking, and
exceptions happen in the event of queues being full at the time of
posting (queues obviously have size associated with them, similar to
stacks).
Allocating memory may block a thread. Does it mean that you are
allocating from a preallocated pool?
Commands in our implementation always get cloned, and whether
arguments are copied or transferred (and whether they are allocated on
stack or heap) depends on their size.
That is very interesting. How do you know if a pointer or a reference
argument refers to a heap or a stack allocated object? The size of the
object being pointed to can not tell you that, can it?
The nice thing of this architecture, is that this typically provides
one with the ability to do ones OOD and Concurrency (or Threading)
design orthogonally. Whether or not a call (or msg) is asynchronous,
depends on whether a command is associated with a server.
Are not commands always executed asyncronously by some other thread
than the one that created a command?
We have
extended the command pattern to handle a number of arguments, and used
mechanisms to ensure that references to one stack is not mistakedly
accessed on other stacks (quite simple, really)
I'd like to take a look at the solution. So far, I could not find means
of doing so, other than to walk through a list of all threads stack
ranges.
We have used this
architecture for a couple of years now, and because of its simplicity
have not considered using, say for instance, something like what
boost::threads provide.
One of the caveats of this architecture, is that the references in a
command waiting to be processed may become invalid. This could be
easily solved by using concepts similar to weak pointers instead of
bald pointers (typically making either mechanisms optional). Of course,
something like GC would be ideal, but the command's association with
the recipient should not prolong the lifetime of the recipient, but
should only prevent the command from executing in the event of the
recipient seizing to exist). We have implemented this scheme on a
number of platforms (I suppose our current implementation can be
heavily scrutinized, but I think the concept is sound).
I must emphasize that this architecture lives within the boundaries of
one process/application, and is only used for intertask/thread
communication.
My questions are:
- Have some of you implemented similar schemes/architectures?
Many has in-house implementations of something like that.
- Could a scheme like this be considered as a viable candidate for
intertask/thread communication in C++. Of course, the notion of
task/thread currently does not even exist in C++.
- The idea is then (to summarize), to create a high level callable
entity in C++ that is associated with a context (or not).
- To have the notion of Context, where context represents what is
currently known as "Thread of execution", each Context just consisting
of code to execute callable entities when they arrive.
There are quite a big number of choices and implementation strategies,
I don't think there would be one thing that provides the level of
abstraction and overhead good enough for everyone.
For example, the fact, that the queue holds a weak, not string
reference to the command, is more of a policy rather than of a
mechanism. Queues can be implemented using containers + synchronization
primitives or using platform mechanism like local datagram sockets.
I believe we have everything in c++ now required to build a custom
infrastructure of this kind quite easily. For example, the one you
described, could be implemented using boost::thread for threading, std
containers, boost::function + boost::bind for commands, boost smart
pointers to implement a specific command lifetime policy.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]