From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

"Valid" actor, race conditions, and data persistence

I have an actor that performs some business logic. It has a separate nested actor that can be launched when a UI is needed for the business logic actor. I'm limiting the number of UI actors to one (for any given instantiation of the business actor). It's possible for the command to launch the UI nested actor to be sent to the business actor even if the current UI actor is running. Hence the desire to check if my UI Enqueuer is a valid actor - the idea is before launching the UI actor, make sure there isn't one already running. I understand why there is not a garunteed check to see if the actor is valid, because it's entirely possible that after receiving acknowlegement that the actor is valid, it could have been killed (race condition results).

I know I'm not the first to want to know if an Enqueuer that I'm holding in an actor is valid or not. Against the recommendation, as a temporary measure, I used the "Equals Not a Refnum" to check if an Enqueuer was at least not the default. I know this method is not robust, leading to possible race conditions, and so I want to find another way to solve my problem.

I received one suggestion to just always kill the UI actor (whether it's there or not) before launching the UI actor. If the UI actor didn't exist, just drop the error on the floor because it doesn't matter. Launch the new actor and there it is. This option is only partially feasible. The business logic is handled separately, so I don't have to worry about the process being interupted or lossing data, just my view of the data. That's the rub though, there may be indicators like graphs that have some history of the received data (yes, it's stored elsewhere, but I'd rather not have to go back to get it) or there may be values in controls that have been set by the user that would be lost if the actor is killed or there may be runtime view changes made by the user.

What I want is a way to avoid the race condition possibility but at the same time, maintaining persistence with my viewer data and settings.

Ideas?

0 Kudos
Message 1 of 2
(3,119 Views)

Suggestions:

1) have the Caller be the only thing that ever kills the UI actors.  Then the Caller can always knows what is running. 

2) send a "Shutdown if you aren't this UI type" message to the UI actor.  The UI will check if it is the provided type and if so shutdown.   The Last Ack message sent to the Caller triggers the start of the new UI.

0 Kudos
Message 2 of 2
(2,741 Views)