Sharing hardware between actors

[BillMe]

I was curious as to what other people may have done when sharing hardware between actors.

I have several actors that need access to a piece of hardware. In this example I have a "power supply" actor that loads and launches the actual/emulation driver actor from disk based on info from an INI file. I'm still mulling over the "hierarchy" but will probably just share the enqueuer of the "power supply" actor with the other actors needing access.

[cirrusio]

I use the Extensible Session Framework developed by David Staab et al.  It essentially uses a singleton pattern to provide a reference to a session (such as a hardware session).  Each new device that requests access to that session increments a count in the class that is a record of how many instances are checked out.  When a device attempts to close that session, the class decrements that count.  When the count reaches 0, the session calls a close function.  This inverts control so that no caller has direct control over the state of the session (inversion of control).  I have used it for all kinds of sessions (files, hardware, etc.) and it has worked well for me.  Check it out.

https://decibel.ni.com/content/docs/DOC-15385

Cheers, Matt

[wrkcrw00]

I have many HW Actors that I share with multiple higher level application actors. Instead of a tree hierarchy, it looks more like a spider web! It doesn't really matter how many applications you have, the messaging structure of the AF allows anyone to send anything to anyone else. This of course is the real problem with this spidre web setup. In a tree structure, the caller and callee are sending traffic to one another, not from the outside, and you control this by not handing out the enqueuers. If you need to however, the real trick is to make sure you hand out enqueuers only to actors who need it.

My solution was another layer, what I call a Signal Abstraction Layer. I'm assuming you have something like a power supply with multiple channels, each channel to be controller by a different higher level caller? I have a the same situation. I break each of these channels up (or groups of them, depending on the application using them) into another actor. That actor is the interface for the application actor. It acts as a gateway to ensure that one application can only interact with the channels it's supposed to, and not allow it to mess with the other channels that may have other critical applications driving them. The SAL also provides a convenient layer to perform analysis, alarms, logging, and other tasks on your channels or data.

I'm working on a factory system that launches the HAL and SAL actors along with several other utility actors. Based on config files, it will distribute the enqueuers to the application actors that need access to particular low level layers.

As in your case above,

[BillMe]

Thanks, I'll take a look at that.

[CaseyLamers1]

I tend to have a single actor responsible for getting data off of a piece of hardware. A copy of that data can then go to each location that it is needed. You can do something like pub/sub to get the data.

[dsavir]

I also have one actor in charge of the hardware, and other actors subscribe to changes in status or ask for data. This way only one actor actually talks to the hardware. I found this easier than the ESF (even though to be fair, I tried the ESF ages ago - I might think differently now).