Reply to thread

Message: [QUOTE="werasm, post: 3548348"] We've create a framework that uses commands (GOF command pattern) to perform inter threading communication. If the applicable command (a member function/instance combination) is associated with a context, it executes in that context, else it executes in its own. All context objects merely have on static function that processes the next command on the queue. Application programmers in general don't think about threading, as it is opaque whether commands are associated with threads or not. In general we prevent the race conditions mentioned by halting on a binary semaphore in the task function and explicitly activating tasks after construction. This is typically done by an object that is responsible for creation of all domain objects (objects associated with context). Typically the context function looks like this: int CmdMngrTaskPosix::taskEntryPoint( CmdMngrTaskPosix* inst ) { //Wait for activation inst->activateSem_->acquire(); inst->execState_ = eExecutionState_Activated; while( inst->execState_ == eExecutionState_Activated ) { inst->serviceCmdQueue(); } //It is highly unlikely that more commands would exists //on the queue after terminate, but flush anyway. inst->flush(); //This is called to release the destructSem_ semaphore // that is waiting for the task to be completed. // destructSem_ will be acquired during either destruction // or a call to terminateExecution(). inst->destructSem_->release(); return EXIT_SUCCESS; } Typically we make use of template method to create all objects, whereafter we start tasks. Obviously tasks can be created on the fly, but the creation and the activation is separated. Each context (or task) has interface that allows for the mailing of commands on its queue. Commands can consist of either member functions or non-member functions. They are cloned prior to mailing over queues. Arguments to the commands are stored as pointers and usually ownership transferral occurs, depending on the size of the argument type. Destruction of a Context Object gets done from an orthogonal context (typically the creator) and the destroyer is forced to block until the context exits successfully. All said, it's quite a large excursion to undertake, but works quite nicely and allows the application programmer to not think "Threads". Regards, Werner [/QUOTE]

Verification