RHAPSODY4YOU

Bob Senegal · Joined: 02 Sep 2007 Posts: 28

Can someone explain me the difference between tm() and OXFTDelay() ?
Are they doing the same things , what are their different use cases

Thanks and .. happy new year my friends

Mickey · Joined: 30 Aug 2007 Posts: 132 Location: Germany

OXFTDelay() is more or less direct OXF call to the underlying
operating system via the OSAL. It most operating systems
the call will end up in a “sleep()”, “tsleep()”, “usleep()” or
a “nanosleep()” or something similar.

The purpose is to fully suspend an operating thread/task
for the given period of time… and to continue from that
point afterwards.

tm() in a statemachine will not suspend a thread, but just
postpone the execution of one single reactive object,
that had been called on that thread. Instead of suspending
the calling thread it will schedule an asynchronous timeout
in order to later signal the calling object asynchronously via
the threads message queue.

From an OXF/OSAL viewpoint this means that an OMTimeout
object will taken from a predefined pool, the delay time
will be set inside of the object and the OMTimeout object
will be put onto the Heap of the OMTimerManager. There
is a parallel TimerTask, which invokes a callback function
of the OMTimerManager in a cyclic way (default: every 100ms)
in order to check, whether one of the OMTimeout objects
on the Heap did expire. If this is the case, then the OMTimeout
will be taken from the Heap and sent to the object, which
originally scheduled the timeout. This will be done via the
reactive object’s activeContexts message queue… which
means it will be handled sequentially (after possibly other
events) by a thread which reads the queue and finally calls
the object.

Typical Use Cases for tm():

* timeout with watchdog functionality (e.g. protocol stack:
when sending a message a timeout can be scheduled when
entering the state where a reply is expected – typically the
reply arrives and the timeout will be canceled before it
expires)

* polling pattern to check conditions in a cyclic way,
where accuracy should not be the major requirement.

* insert delays in a sequence of action steps modeled
via a list of states performing the action steps as entry
actions.

* call cyclic actions if accuracy is not the major
requirement

Typical Use Cases for OXFTDelay():

* suspend an operating system thread for a given period
of time before continuing its activity. (This is similar to
what the TimerTask does between calls to the callback
function of the OMTimerManager).

* perform cyclic activities (like calling PID loop control
algorithm) with a rather accurate cycle time from an
independent thread (thread priority can be increased
to ensure accuracy within operating system abilities).

Easy isn't it

Generally bad Use Cases:

* OXFTDelay() should not be used in statemachines.

-> This is the case, because not only the calling object,
but the whole event processing for any other reactive
object sharing the same thread will be delayed by
suspending their common thread.

* tm() in self-transitions of a state in order to call cyclic
operations with high precision timing requirements.

-> This may get inaccurate especially if multiple objects,
which cause many events on the queue, share the same
thread and may thereby cause delays for consumption of
OMTimeout events.

-> Besides that, the accuracy is in general limited by the
TimerTask resolution (default 100ms) and the accuracy
of the underlying operating system feature used in the
OSAL.

Thanks to Luke ... may the force be with you

Farquad · Joined: 13 Sep 2007 Posts: 172 Location: London

Just to add that you can create a timer object via the OSAL.

OMOSFactory::instance()->createOMOSTickTimer(time,callback,param)

This means that you get a callback rather than having to wait for the timeout event to arrive via your activeContext (the thread that's looking after the object)'s event Q.

Of course you have to be aware that the callback function could then access data that may also be accessed via your activeContext.

You might choose to guard your data. A guard will automatically create a mutex via a call to :

OMOSFactory::instance()->createOMOSMutex()

Only one mutex will exist for each class regardless of how much guarding is specified.

You could create your own mutex via a direct call to the factory.

Incidentally, when you make a class active the associated base class, OMThread, will create a thread through a call to the factory.

OMOSFactory::instance()->createOMOSThread()

It is important to understand the role of the OMOSFactory in order to feel at ease with Rhapsody's code generation and how it achieves built-in portability.