Hi,

is there a possibility to join an OMThread-instance? Or any other simple method to wait for a thread to cleanly finish?

Christian

you can add another object to a specific OMThread instance ... either graphically through structured class where the structured class is an active class or a property called Activebase - if I remember well - is this what you need ?

Hi Bob,

thanks for your reply. But I don't quite get what you mean. You mentioned two possible solutions:
1. Adding another "object" to an OMThread instance. -- What kind of object would that be? And by object you mean instance of a class? And what would that object do?
2. Using a customized base class for all my active classes. Hmm, if I could simply make the OMThread joinable, this would seem a reasonable approach. But I think it is not that simple. Rather I would end up writing my own OMThread implementation from scratch -- and that is definitively not what I want.

btw. I use a general purpose approach now where every active class needs to derive from a class I call Controllable. The counter part is a Controller. A Controller can have several Controllables (and be itself a Controllable). A Controllable requires two methods to be implemented: start() and initShutdown(). And it provides one method for the derived class: signalTermination(). So, when the active class finishes it simply calls that method.

I simply wonder why no one else seems to stumble across that issue.

Regards,
Christian

I will admit that I don't know what you're talking about. I don't understand what you mean by the concept of 'joining a thread'.

Hi Farquad,

when you join a thread you wait for it to finish, i.e. when the OMThread::execute() method returns. Typically join() would be one of OMThread's methods. The one calling it is usually the same who started the thread.

At the moment I need this functionality when I want to shutdown my application. I need to make sure that every thread finishes before exiting the application.

For a more detailed explanation have a look at the man page of pthread_join() or the documentation of Qt's QThread class (http://qt.nokia.com/doc/4.5/qthread.html -- the wait() method)

I have the feeling that a related issue masks that flaw: By default, OMThread promotes an asymmetric usage. You create a thread and start it. But you never destroy a thread or wait for it to finish. Instead, the thread destroys itself when it returns from the execute() method. I usually force a symmetric behavior by calling setDeletionAllowed(false).

I also have the feeling that most people don't care about a clean shutdown of their application. Even the support told me that Rhapsody is designed for applications that simply run forever.

Hope that clears things up a bit.

Regards,
Christian

not an easy one

Christian,

Thanks for posting your comments about calling setDeletionAllowed(false). Seems crazy that the default behavior is to have the Thread Class handle the delete for you.

Hi DanD,

totally crazy! Same applies for reactive classes: When a reactive class reaches its termination connector it deletes itself. The magic call here is setShouldDelete(false). So when you have a reactive class that also is active you have to issue
setDeletionAllowed(false) and
setShouldDelete(false)
to have a symmetric behavior.

Obvious, isn't it?

Regards,
Christian

At the least you would think they would document it clearly that this is the default behavior. I am finding much of the Rhapsody documentation incomplete.

There's a model of the framework under the oxf directory. The code is generated from that model.

Interesting approach... unfortunately there seems to be a kind of a paradigm conflict here, right?

This looks like an attempt to apply a Linux/Unix specific concept like joining a pthread to the Rhapsody object execution framework. Unfortunately - even so that the name 'OMThread' seems to be similar - the OXF is not really based on Linux/Unix and on posix threads... it just uses them as one possible implementation of a thread concept. But in general, the concept is (tries to be) platform and OS / RTOS independent.

For that reason 'pthread_join()' cannot be applied - it would simply break the OS independent abstraction layer and kill portability of applications across operating systems.

Of course, one could create a platform dependent layer, and optimize it - e.g. for 'pthread' based operating systems. This could be done by either removing the 'OMOSFactory' and the 'OMOS' interface classes and by using direct calls to OS-services, or it could be done by extending the 'OMOSFactory' and the 'OMOSThread' in order to add that concept for several platforms. The OXF contains an abstraction layer (classes IOxfEvent, IOxfTimeout, IOxfReactive, IOxfActive) in order to create an independent realization of the behavioral framework. There is even a set of properties under CPP_CG::Framework in order to tell the code generator to use a different set of implementation classes.
The only disadvantage is, that a major number of embedded realtime systems (which are a Rhapsody target 'sweet spot') may not be compatible and someone will need to start maintaining such an alternate concept across upcoming versions.

But is that really the main question? What is the Use Case?
Why symmetric behavior? Why no asynchronous behavior? What are the pros and cons here?

Since I do not (yet) know your Use Case, the only thing I can do, is describe my understanding of the OXF concept.

You may have seen, that the main Use Case of OMThreads is queueing/handling asynchronous events (derived from OMEvent, OMTimeout) within its OMEventQueue and pass them forward to various receivers, typically statemachines (derived from OMReactive). Any object from any thread can send such an asynchronous event at any point of time by calling the destinations operation (OMReactive::send) to send him a message via the queue of 'itsActiveContext'.

Now how would one shutdown such an asynchronous event processing thread in a clean way?
There are mainly two options:
* synchronously,
* asynchronously.

There are several pros and cons with each of both approaches - and the OXF tries to allow using one or the other concept:

How?
* destroy instances of reactive classes (statemachines) asynchronously:
- either send an asynchronous event that triggers a transition to the 'T' termination state,
- or call the 'destroy()' operation of the instance (either generated or inherited from OMReactive).
=> in both cases a flag to disallow further event reception will be set and an instance of OMReactiveTerminationEvent (an internal framework event) will be sent to that instance twice. The first one to clean the OMEventQueue, the second one to tell the OMThread to delete that reactive instance after the queue was cleaned up.
* destroy instances of reactive classes (statemachines) synchronously:
- call setSupportDirectDeletion(true) for the specific instance in order to enable this behavior
- call either 'pObject->destroy()' or 'delete pObject' to delete the object synchronously.
=> during a synchronous iteration through the OMEventQueue of the active context's OMThread, any existing events targeting the under destruction object will be canceled,
=> this must only be done from an object executed on the same thread, because otherwise the event dispatching would continue (modifying the queue in parallel) while that iteration happens.
=> there is no mutex protection for the iteration due to possible deadlock situations.

A similar approach exists for instances of active/reactive classes (active class with statechart and/or active class containing embeddable objects with statechart).

Pure active classes without an own statechart and without any nested reactive object are a little different and must be handled by the user...
Typically they will overload OMThread::execute() locally, because the thread's main loop will not dispatch an event queue. Instead it will read from another kind of blocking device. In such a case OMThread::endDispatching() shall be overloaded as well, in order to enable an external trigger for terminating the thread object.
The default behaviour in Rhapsody is asynchronous deletion of thread objects, because this approach allows to continue/finish processing events already on the queue (including termination events for reactive parts) and then exit the loop before finally deleting the object.

OMReactive::setShouldDelete(false) is a different thing and is meant to be used by the code generator. It will be called in the constructor of a structured class in order to disable self-destruction of embedded objects which have been instantiated as an attribute of the structured class.

If a class inheriting from OMThread shall do some notification before exiting, then I would recommend to overwrite OMThread::execute like that:
OMReactive* MyClass::execute() {
OMReactive* result = 0;
result = OMThread::execute();
notifySomeone(); // preferably send an asynchronous event in order to delay processing/allow completion
return dummy;
}


A good way to understand the framework is generating a set of different design patterns and observing how the generated code takes advantage of the framework classes and operations.

A better way may be to ask IBM for some training or consulting on that topic.

Best regards,
Luke.