Dynamic process change - Process handoff

[shoneill]

I'm considering a change to some of our code running on a RT and have a question.

I'm thinking of generating LVOOP-based "services" on the RT whose DD VIs are called in parallel to the main processing loop and communicate via queues or some other as yet undefined asynchronous mode. The reason for this is that the individual DD calls are WAY too slow for us to be calling in every iteration of our main loop.

So assuming I would have this up and running, I would of course like to investigate the option of changing the object for a given service "on the fly". How does one go about this? I would assume that the new object instantiates itself in parallel and then "takes over" the processing of the service requests. Of course the current state of the object to be replaced needs to be considered but my question is if there is an established method for doing this.

Does anyone have experience of such a process handover, or even know what this is typically called?

Shane.

[PaulL]

Shane,

If I understand correctly then you want directives (commands) from your main processing loop (client) to find the appropriate target (receiver) to execute them. This is exactly what the Command Pattern does.

Yes, it is possible for each Receiver to maintain its state.

We actually combine the Command Pattern and the State Pattern to do exactly this. Our solution differs from what you describe, since the Receivers do execute their atomic actions within the main control loop (of course in parallel to the View). If a Receiver broader action (e.g., a point-to-point axis move) requires a long time, we break up the action into smaller pieces (not segments, but, for instance, "check if we are there yet" actions each loop). In other words, we use a Run-To-Completion execution model.

Does this help?

Paul

[shoneill]

Paul,

that's pretty close to what I'm looking at but my question is about the details of replacement. I don't want the REceiver to change while the sender is waiting for a command to finish because this leads to some swkward situations.

I think I simply need to initially allow both to run in parallel and have some kind of "Get Receiver" at the start of any set of commands which must be executed on the SAME receiver and only when a receiver has no open listeners, can it be closed after receiving the "close" command. That way and pending commands will be finished before any real handoff takes palce. I essentially don't want the sender to know what type of receiver it's communicating with. I don't want it to have to know, I want plug-in receivers.

Shaen.

[asbo]

Why not make the substitute receiver send a message on the same queue the sender uses and let the substitution command be handled in sequence by the current receiver, which guarantees that you don't have to add extra logic to check if the current receiver is "busy." This assumes each command is atomic - that is, the sender doesn't say "DoAcquisition" and then poll "DataReady?" or "GetData."

[JamesMc86]

What are these VIs doing? Are they too slow because of the processing or because of the dynamic dispatch.

I am intrigued by a form of channeling pattern for processes so that you can have common code. Swapping the dd vi means changing the object type so I gues you need some form of fsctory method which loads the new object with the new VI. I would think about breaking down these processes in a more defined and/or fixed way though where possible. I highly doubt this will be faster than an inline VI (but will make the code parallel) and debugging is going to be a nightmare if the processes do have fixed responsibilities.

[shoneill]

What are these VIs doing? Are they too slow because of the processing or because of the dynamic dispatch.

I am intrigued by a form of channeling pattern for processes so that you can have common code. Swapping the dd vi means changing the object type so I gues you need some form of fsctory method which loads the new object with the new VI. I would think about breaking down these processes in a more defined and/or fixed way though where possible. I highly doubt this will be faster than an inline VI (but will make the code parallel) and debugging is going to be a nightmare if the processes do have fixed responsibilities.

You can't inline a DD vi. Alone the overhead for calling a DD Vi is prohibitively expensive in our system. We're pushing a RT system to its limits.

The actual code WITHIN the DD Vi is quite fast but we can't afford to have the DD overhead each cycle, hence the handoff of parallel-process handlers.

The parallel processes (Different objects) would receive and respond to the exact same commands fromt he main loop, would use different criteris to evaluate the time to move to the next stage (for example). Therefore they should be transparently hot-swappable . If the actions were atomic, it would be no problem.

Shane.

Shane.

[JamesMc86]

Sorry inline was a bad turn of phrase, what I meant was a subVI in the process rather than a parallel process. I'm not sure what target you are using but if you are pushing it that hard then I would think that the transport of the data and thread swap maybe a problem overhead as well but it would be interesting to know if not. That being said if the process can continue processing data while the main thread continues then this would seem a good way to go.

I would be interested to know how this goes, I'm always intrigued by oop on RT and primarily where it might break down.

[shoneill]

Sorry inline was a bad turn of phrase, what I meant was a subVI in the process rather than a parallel process. I'm not sure what target you are using but if you are pushing it that hard then I would think that the transport of the data and thread swap maybe a problem overhead as well but it would be interesting to know if not. That being said if the process can continue processing data while the main thread continues then this would seem a good way to go.

I would be interested to know how this goes, I'm always intrigued by oop on RT and primarily where it might break down.

Ok, now I get your "inline" comment. No problems.

The data sent between the main loop and the parallel loop is negligible. It's basically a simple status set and a subsequent status read (which I will do via a simply Queue read and write which shoukd be fast enough). I want to tell the parallel process to start and then in each loop of my main process check the status accordingly until it's finished. The parameters required for the parallel process can thus be completely separated from the main loop reducing complexity I think.

I'm trying to go a minimal "component" route.

Nothing's implemented yet, I'm just in the thought process.

Shane.

[JamesMc86]

Ah ok that sounds like a good route. I would guess something based off the state pattern sounds like a good idea then, although in this case rather than direct API being the interface the queue provides that.