Hi all,

Please think of three classes : A, B, C, shown in the UML object model diagram attached.

A creates instances of B and deletes them later as it is required.
B, while living, asynchronously subscribes to a specific instance of C, to be able to get some specific data.
Subscription occurs in the following way:
mC->GEN(evSubscribe(x,y, this)) //x and y are just two variables determining the way of subscription.
After this event is processed by C instance, subscriber (B) will be notified whenever appropriate data is obtained.

The question is this:

Whenever A wants to delete an instance of B ( by calling "delete pB"), which has already subscribed to C, deletion becomes problematic if
that specific instance of B is not first removed from the subscription list of C. Otherwise a crash occurs whenever C sends data to the subscriber, which is actually the deleted instance.

However, I am confused how this should be solved.

I do not want to make A become aware of C and subscription issues.

An idea, I tried to realize, is sending evDelete event to pB and let it handle unsubscription issues by itself. After a verification coming from C (evUnsubscriptionOK), I want the instance to delete itself. Is that possible ? It seems not.


And I do not know how I can apply GUARDED_OPERATION concept here.

Not that, A,B,C, each runs in different active contexts.

Problem may be summarized as "how should the design be whenever the object, which is about to be deleted, is subscribed to a list which is managed by another context ?"

Waiting for help.

Bit unusual to send an event evSubscribe rather than just making a direct call. I'd probably have a Subscribe() and Unsubscribe() operation in C that B uses. I'd then make B call Unsubscribe in its destructor.

Alternatively if you want to do it with events see diagrams. Note that you should avoid calling delete on a class with a statechart, instead use destroy or get it to run to the Termination State.

B has now got behaviour so you'll need to call startBehavior after newing it and setting itsC.

Hi, thanks for the quick reply.

I need some more clarification about two issues.


First, Making class C have two operations (subscribe, unsubscribe) available for B's usage is really good but different active contexts bring some complexity, I think.

More clearly; subscribe() and unsubscribe() methods will access a list of subscribers. Moreover, a third operation (namely, doSomething() that will be called upon the reception of evUpdate() ) will also access to that list, in order to determine subscribers , so that subscribers will be notified about the incoming data. So, even subscribe/unsubscribe method calls are performed from within the same context ( the context in which B runs) , the third method call will be done in a different context (the one in which C runs). So, the list should be protected, shouldn't it ?
Think of a scenario, in which the following steps are observed.

CONTEXT-1
1. A subscribed to C Time-1
2. A unsubscribed from C Time-5

CONTEXT-2
1. Data received by C Time-2
2. Data processed by C Time-3
3. Subscribers are found by C Time-4
4. Subscribers are notified by C Time-6

So, problem occurs after Time-5 if no protection is provided for the list access.

For that reason, I plan to use the OMOSMutex lock/unlock in all above 3 methods so these two different contexts live happy together, wouldn't it be correct ?

Second, making a state transition go into Termination State does not destroy my object automatically. Should I have taken another step ?

Regards.

Özgür Eser Akdemir

Termination state should work.

Hi, again.

The term "termination state" is the source of my confusion. There are two "termination" related entity in the Rhapsody.
One is the "termination connector", shown as a green circle, with T written in it. This is what you used in your example and it really works, destroying the object.
The other is the "termination state", shown as a white circle, with a smaller black circle in it. This is what I tried and it does not destroy the object.

And followings are definitions given in the help :
- "The termination connector is the suicide or self-destruct connector. If a transition to a termination connector is taken, the instance deletes itself. A termination connector cannot have an outgoing transition."
- "A termination state provides local termination semantics. Local termination implies the completion of a composite state without the destruction of the context instance."

I now wonder, why does anyone ever use "termination state" ? What is the use of that ?

Second issue is the concept of guarded operations.
I still do not understand how a guarded operation can avoid the complication I described previously.

The guarding you pointed locks a mutex at the beginning of the method call, unlocks at the ending, doesn't it ? If so, it guarantees that no more than one task can execute the function at the same time.

However, the problem is guarding a resource, namely a list, and this list is subject to change by 3 different methods, 2 of which are called in one context ( in which B runs), 1 of which is called in another ( in which C runs )

"guarded" just allows sequential access to that operation, how can it protect the shared resource, here the list, when different operations are trying to change it within different contexts ?

Just to make the problem statement clear :

C (CommunicationService) keeps a list of B (Monitor), as subscribers . Both run in different contexts.
C is responsible of finding the relevant subscribers in the list ( by iterating thru the container list) to determine which subscribers should be notified about the reception of data. B objects may unsubscribe at any time. If this happens when C is in the middle of finding process, application may crash since the list has changed due to synchronous call of "Unsubscribe". ( Think of invalidated iterators C will experience while iterating the list of subscribers )

I do understand your issue is about multi-threading and this will work because all guarded operations in the same object use the same OMProtected object so only one Guarded operation can be entered.

To understand this, take a look at the macros in your generated code. You will find the code for those macros in your oxf directory in the OXFGuardMacros.h file. You will need to study OMProtected.h and .cpp for the full story.

Once per class - OMDECLARE_GUARDED

In each operation - GUARD_OPERATION

Note that the current owner of the guard may still call another guarded operation of the same class from within a guarded operation.

Dear Farquad, thanks a lot.

My perception about the guarded operations was not correct and this discussion has been a good chance for me to correct it.

Best regards.

Özgür Eser Akdemir

As an extension to the above discussion, I have a question about "guarded" synchronous method calls.

It is well understood that

1 -Events are used to asynchonously communicate with an object . They are able to trigger transitions, based on the statemachine provided.
2- Calling Guarded methods synchronously is another way of communication.

But what about if it is required that a synchronously called guarded method should trigger a state transition ?

You should probably use events in that case. Need a specific example to explain it though.

Triggered Ops are available in Rhapsody but should only be used if you know exactly what is going on.

As an example, think of a class (A) with the statechart shown in the attachment.


And let us assume that many events of type evData are accumulating in the event queue, each with such paramaters

5 ( 1st event) , 6, 11 , 14, 8, 2, 17, 26 ( 8th event), 18, .....

According to this sequence, the 3rd sample (value =11) will trigger a transition from Green to Yellow, and
the 8th sample (value = 26) will trigger a transition from Yellow to Red, if only events are used.

However, another object (B) needs to call this class' "reset" in a syncronous manner, to make the state emergently go into "Green". (By the way, assume that the calling object uses the return value of method reset() , which is the total amount of values received so far via each evData event.)
Calling reset() may take place at a time where an event is still being consumed (in the context of B) but not finished due to preemption.. So, what will happen after reset() does its job (in the context of A), changes the state ( Yellow -> Green ) , and returns ? Pre-empted job (processing the evData) resumes again, but now state changed due to reset() just called as a triggered operation ! How will the framework behave in such a case ? Here, should I guard every event handling operation as well as the reset method ?
I get confused..

If I use evReset, adding a transition from Yellow to Green, how can I return that total amount to the requester ? By adding a callback pointer parameter to the event ? Moreover, evReset will wait until all the previous events to be consumed, won't it ? This will mean waiting some time before the resetting is performed, which is not good.

So, could you please tell me how I can safely use triggered operation with events at the same time ?

"Calling reset() may take place at a time where an event is still being consumed (in the context of B) but not finished due to preemption.. So, what will happen after reset() does its job."

This is a little confusing but I think I get the jist. BTW params->value > x should be < I think.

evReset is a triggered operation rather than an event. Otherwise it gets queued in A's context and that's not what you want I think.

So you'd like reset to change the current state synchronously while the statechart is already in transition?

This is not possible. The statechart code is not re-entrant so an attempt by another thread to get in with evReset will be ignored and the call is lost. Take a look at the omreactive.cpp code in the oxf directory. The operation OMReactive::processEvent checks the busy flag and calls handleNotComsumed if true. Unless you, yourself, provide an implementation for handleNotComsumed the event/trigger just gets lost.

Perhaps you should set a bool 'reset' attribute in handleNotConsumed and have something like this? You should know that all null-triggered transitions are evaluated at the end of processEvent so the [resetPending] guard will be evaluated should the trReset bounce.

Thanks...
I hope to digest through the weekend..