Re: Multitasking in C++...

Maxim Yegorushkin wrote:


We do have multiple message queues. Each "worker thread" (as you call
it), consist of a function that extracts the next message from a queue.
Only one CommandServer can post to that queue. I have seperated the
responsibility of servicing the queue (CmdMngr) and processing commands
(CmdSvr). (Very) Basically things look as follow:

class ExecutableCmd
{
  public:
    //...omitting detail...
    virtual void execute() = 0;
};

class ProcessableCmd : private ExecutableCmd
{
  public:
    //...omitting detail...
    virtual ProcessableCmd* processClone() = 0;
};

class Cmd : private ProcessableCmd
{
  public:
    const Cmd& operator()()
    {
      if( svr_ ) { svr_->process(*this); }
      else{ execute(); }
    }

  private:
    CmdSvr* svr_; //Could be weak_ptr...
};

Cmd is basically the baseclass that holds the logic wrt. processing of
itself. It is a little more complicated, but basically boils down to
above.

Priority (below), when critical typically allows a command to be
inserted in front. We don't use it often though.

class CmdSvr
{
  public:
    void process( ProcessableCmd& cmd, int timeout = 0,
      eCmdPriority prior = eCmdPriority_NORMAL ) throw();

  private:
    virtual void processImpl( ... ) = 0;
};

The CmdSvr typically has a few more responsibilities not apparent here,
such as the ability to disable and enable posting etc, which we have
found a handy feature during debugging of multithreading apps.

Then (lower down in the hierarchy) we have a class responsible for
owning context, and executing commands in that context:

class CmdMngr : public CmdSvr
{
  protected:
    void serviceCmdQueue() throw();
};

serviceCmdQueue is a template method that prescribes the process of
executing commands as they are retrieve from the command queue. For our
implementation, all derivatives call this from within their task entry
point... typically:

while( 1 ){ serviceCmdQueue(); }

only slightly more elaborate, handling things such as flushing of the
queues etc., and activation by means of binary semaphore.

It must be noted that only commands can be sent over queues, and that
the entire application really exist of parallel threads (or workers),
each responsible for processing commands received on the queue that it
owns only. Each CmdMngr is responsible for handling exceptions raised
by the code that it executes (It is associated with an interface that
propogates exceptions - exceptions deriving from std::exception don't
propagate above this layer.


A command server has parts executed in the contexts of the actual call,
and a part executed in the context of the thread that it represents.
The part executed in the context of the actual call is always
non-blocking. We have provided interface for the ability to block, but
we have found that this is never necessary (i.e. timeout currently
always zero). If the queue is full, and the time specified (zero...) is
not met, then an exception is raised (if preferred), else the command
state indicates the failure. A command cannot be processed before
current failure state is not cleared. The part executing in the context
of the task/thread associated with the server, blocks at the queue
until a next command arrives to execute. It always blocks, therefore a
command server (Actually, CmdMngr, which is-a server) is always waiting
for the next command (except while processing the current one), and
cannot miss it if it was put on the queue.


I suppose a counting sem was an overkill - you are right.
Maybe/probably even slows things down. The queue does have that
knowledge (to know that it is empty). I could toy with implementing my
Windows Mailbox by only using a binary sema (or an event) as signal.
Currently I use critical sections to perform mutual exclusion.


Yes, it does :-). In this environment, there are unfortunately 2 more
decisions that you have to make:

1. How much are you willing to queue. I only queue cloned pointers,
btw, which makes things quite efficient.
2. How much you are willing to queue, and the sizes of your commands
and their arguments are an indication of how much memory you need to
pre-allocate, sadly.

I must mention that I have started looking at using boost pools over
the range of sizes expected. Example:

pool 64 bytes
pool 128 bytes
pool 256 bytes
pool 512 bytes
etc..
heap.

If a pool was not provided for a size required, we loan from the heap
and it is logged - very rare. The pools have an initial size estimate,
and grow as required. We don't have this scheme currently though, we
have a scheme of queues (thread safe, of course) that are pre-allocated
(by guessing). We have a little bit of pointer hiding in the memory to
the stack to which the memory must return, and when looking for a
specific size, we use a binary seach. If a specific size does not
exist, we lend from the next up until we find a pool that has
something, else we lend from the heap - which is very rare. I have
toyed with this in comparison too the boost::pool. I think it was very
similar wrt efficiency. boost::pool is more scalable if one gets the
sizes wrong, though (in that the heap is less likely to be used).


Yes, good question. The only reason we consider the size, is that for
large objects, we want to prevent additional copying. For small
objects, we send a copy of the argument over. For large objects we send
a pointer over (and only perform one copy) - the joy of templates. For
references (if the callback receives are reference), we store a copy or
a pointer to a copy. We never store the reference, as the mistake of
sending a reference that exist on a calling stack can easily be made.
Simple, if <T&> typedef T ArgT; Then, after that, the size of ArgT
determines the storage type, so to speak. For pointer storage types,
ownership is released after execution, and the cloned command receives
ownership, until it is destroyed after execution. All arguments are
also pre-allocated, if they happen to be pointers due to large size (a
thing to determine is at what size it become worth not storing the
actual type - this is currently a thumbsuck).


If associated with a CommandServer, yes. We do have a scheme similar to
ADA rendezvous, though (if I understand it correctly), where one task
blocks until another task has completed execution of the command. This
is effectively a synchronous command, then. We have found some use for
it, but quite rare. This is implemented wrapping a binary semaphore
with a Mutex. The recipient signals when the call has completed. The
sender waits at the bin sem. The mutex prevents races... This is
dangerous, though, as it often happens (during implementation of Harrel
State Charts), that we use commands to unwind the stack (also handy).
If a command is executed in the context of a server with who it is
associated, and it takes perform a rendezvous, instant deadlock. Other
more interesting scenarios exist :-). One of the uses in which I have
found this helpfull, is during graceful termination of threads from
other contexts/threads. This has been abstracted though.


As I've explained, we used the conservative approach. We use function
templates to derive the applicable command. The arguments are derived
from the member function pointer arguments. If the recipient receives
references, we always copy. Depending on the size, we either copy once
and transfer ownership, or we copy twice - once during the call, and
once during the clone. If the argument of the callback function
receives a bald pointer, we assume the caller knows what he is doing. I
allowed this as sometimes one wants allow associating to (or breaking
associations with) other classes over threads - This reduces mutual
exclusion contention :-) - I suppose not so conservative. I have
created specialisations for std::string and character pointers.
std::strings COW techniques have hurt me bad in the past, and the
specialisation performs explicit copying from one string to another.

Wrt to implementation, I suppose I could mail you - quite big though.
Currently there are still some caveats. Like the receiver of the
command is still a bald pointer. I have been meaning to change that for
a while, but I first have to get boost working on all our platforms...
VxWorks for one (I have not yet found the time). Our current systems
work well despite this, though - but only because we aware of the
caveat.


I was not necessarily aware, but was wondering along those lines. Hence
my idea of standardising. I'm sure they could provide one with some
good options if they try. They being the ones that realize the standard
- us? I think the idea is good, but I don't think I'm the best
implementor - not to bad, I suppose, but there are better people suited
for the job :-). I thinking people of the likes of erdani etc. I did do
our inhouse implementation though, and it promises more than what is
currently available (IMhO).


Hmmm, Java was brave enough to try something. I have not yet looked
what C++/CLI has come up with. I venture something like GC would be
beneficial. I especially like the notion of two phased destruction,
where true ownership exists (and hence deletion), but all references to
the original become aware of its non-existance, which they can test
before calling. This is more-or-less what weak pointer gives you (wish
it was standard). It would be ideal for this use, typically.


Yes, true - but providing a consistent interface (dictating an
interface), will allow various implementations to do the same thing.
Typically, one only need a container of pointers for this exercise,
ever (behind a consistent notion of something like a CmdSvr).


Yes, as we have. But standard would be so-o-o-o much nicer. How about
it. Incorporating a nice simple mechanism that abstracts OOD from
Concurrent D. Our inhouse scheme was easily portable between 3 very
different platforms. Java (what a bore of a language:-) - maybe just
kidding) provides more wrt. architecture. The unwillingness to get
things wrong the first time prevents C++ from providing a solution at
all. boosts constructs are at too a low level, but I agree, could be
used. My tasks look very different to theirs though, but probably
because I did not learn from POSIX.

Thanks for your response, It was insightfull.

Kind regards,

Werner

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]