Data sharing between actors and reply messages.

[MartinMcD]

Hello there,

I have a similar question to the recent DVR/data copy post because I need my actors to be able to access some shared data and I always come up against trying to work out the best way of doing it.

Assuming I have some sort of central database that contains information that lots of actors need to access. Then I could:

• Give the actors that need it the enquerer for the database actor so that they can talk to it directly
• Use the sychronous ReplyMsg so the actor wanting to check a sensor calibration (for example) can do so without a traditional call/response msg

This technique seems analogous to the traditional way of unbundling a cluster to read local data; sharing data like FGVs; data-classes-with-DVRs etc. However, I 'know' synchronous messages are to be avoided, messages should be announcements eand so on.  So assuming I don't do that I have some new options:

• Use the standard asynchrous message and deal with it
• Avoid having to ask for a sensor value in the first place - kep a local copy of the data and on every change of the database a new database will be pushed out to us, seems inefficient
• Use a data-class-with-dvr rather than an actor, but lose the benefits of having an actor
• Use an FGV/global with the drawbacks of all that (no dataflow, single reference, easy to mess up)

So my question is - is it so bad to use the synchronous message; I may be being niave but it feels like it would be okay for what is essentially a cluster unbundle operation.  If so, can anyone point be in a more fruitful direction please?

Thanks,

Martin

[komorbela]

I have nothing against sharing the enqueuer of the database actor, I think that's ok.

But I would not use sync(hronous) messages:

If you are extra sure that no one never ever will send sync messages from your database actor, than it is ok. But in case in the future someone decides that it might be good to send sync message from the database to one of the requester actors, your program will just simply freeze when a pair of these sync messages happen in the "same time" - actually one starts before the other finishes.

If you are OK with receiving Variable data type (as you would get this with sync messages) than I would suggest to send the requester actor's enqueuer to the database actor in the request message.

All the requester actors should have a common message with Variable data type. It can be a common message in the following way:

Have a common parent class for all the requester actors and create a method that receives the Variable data (and outputs it or writes to the actor's private data). Than you can use the receiver method in the child classes and add any custom method to it by overriding it but using the "Call Parent Method" in it that gives the Variable data for you.

So this message should be sent by the database actor when it wants to send the requested data, sending it using the received enqueuer (address of the requester actor) that was included in the request message.

I just made it up so it can have problems, but I guess not so serious as the synchronous messages. I hope it helps you on your way.

[AristosQueue (NI)]

MartinMcD wrote:

• Avoid having to ask for a sensor value in the first place - kep a local copy of the data and on every change of the database a new database will be pushed out to us, seems inefficient

I would encourage you to look into this. The whole "seems inefficient" is the same theory that held us back in the development of the AF in the first place. Really, we don't see the problem with this approach in practice. As long as you don't push the whole database out to every actor but only push out the changes that each actor says it is interested in, the performance gain from each one not having to synchronize when it actually needs data is substantial. There are concerns about timing windows (one actor hearing about a change sooner/later than others) but those are the same concerns you have with the centralized database lookup (one could look up the value right before the change and start its operation and the next could look up right after the change and start its operaion and the two operations are happening at the same time with different settings). In both situations, if you need to control that no one is operating at the same time with different values, you need to add messaging that says, "Everyone has the new value and we will all begin using the new value at timestamp X" -- or one of the infinite variations on that theme.

Especially on the desktop, you are working with an environment where memory is plentiful and the bottlenecks to parallel performance are the friction between processes. This is often true even in RT environments. I encourage you to explore your feelings of "seems inefficient" and see if your concerns are real or imagined.

[MartinMcD]

Thank you for the responses, I will spend some time thinking through what you've both said.  Regarding the 'seems inefficient' feelings, I think I am scarred from a former life programming 8-bit microcontrollers, I need to shake it off.

[fabric]

If all else fails a functional global or DVR inside the actor class with a private Write method and public Read method is simple, efficient and only mildly blasphemous in these parts of town... That's my weapon of choice when the bookkeeping for a pure publish/subscribe architecture gets too complicated!

[AristosQueue (NI)]

MartinMcD wrote:

Thank you for the responses, I will spend some time thinking through what you've both said.  Regarding the 'seems inefficient' feelings, I think I am scarred from a former life programming 8-bit microcontrollers, I need to shake it off.

It's common across all of us who have been programming more than, oh, about 5 years. The multi-core systems have radically changed what software architectures are highly performant, and when you couple that with the ability to relatively easily push processing onto the FPGAs, the entire structure of software gets up-ended.

For the record, I don't do work on FPGAs hardly ever, but I've been sitting in on some app design meetings, and treating the FPGA as a remote actor is exactly right. Those of you on this forum who do work on FPGAs... it might be interesting to work out how to create an AF that can deploy onto an FPGA and have as much of a clean interface back to the RT or to the desktop as possible. No dynamic dispatching on FPGA makes our current infastructure a non-starter, but there may be some possibilities with some sort of "message class to integer enum" conversion sequence. Putting such together would be truly pie-blue-sky-and-pipe-dream engineering insofar as anything else from the AF is pretty much non-applicable. But the model of it as a message target that replies asynch is *exactly* right.

[MattP]

I've actually been thinking about this.  There is a way to do it, using DMA FIFOs as the message-passing mechanism.   On the newer FPGA targets (PXIe FlexRIO, 9068 cRIO, etc) we have 16 DMA channels to use, so allocating one host->FPGA and one FPGA->host DMA FIFO for an actor is no longer as unreasonable as it was with the older targets that had a limit of 3 DMA channels.  

There would still be no dynamic dispatch, but the ability for the FPGA to asynchronously receive messages, do something, and publish information out to a waiting actor on the host side is doable. 

I implemented something like this a while back that used a host-side API to abstract out the fact that the co-processing was happening down on the FPGA, moving that host-side code into an actor is not that hard.

[drjdpowell]

fabric wrote:

If all else fails a functional global or DVR inside the actor class with a private Write method and public Read method is simple, efficient and only mildly blasphemous in these parts of town... That's my weapon of choice when the bookkeeping for a pure publish/subscribe architecture gets too complicated!

What you all need is a framework addition that makes providing information to other actors, by message and asynchronously, simple and easy.