Best way to handle shared resources in AF

[Jeannius]

I am building an application involving various instruments and sensors. Some of those sensors communicate with Labview using a USB host adapter. I decided to use actor framework to facilitate communication.

I have modelled each instrument as an actor. I have also done the same with the sensor. Should I model the USB host adapter used by some of the sensors as an actor too? I am not sure how Labview would handle this. Any insight is greatly appreciated.

[cirrusio]

Hey Jeannius,

This is an excellent question.  I have a similar situation in which I have some devices communicating on serial ring networks, but each device is handled by it's own actor.  Not sure if this is the best way to go about this, but it is the way I have chosen.

I have used the extensible session framework (ESF) pretty heavily to accommodate shared resources, but I am now reexamining this in light of my understanding of DVRs.  The ESF is a pretty good way of accounting for objects that use a shared resource, but the way it goes about this by using a DVR and then checking out the DVR to each subscriber.  The ESF keeps track of these references by incrementing an integer and storing that value in a notifier.  Each time a new session is obtained, the value is incremented.  Initialization is only performed on the session at the first checkout.  Each time a session is released, the value is decremented and the session is officially closed when the counter reaches 0.

The issue I have with the ESF is that the lifetime of DVRs is tied to where they are first obtained.  This means that in your architecture, you may have a controlling actor which launches your actors which require access to the session that you have created.  If you close the controlling actor before the devices are closed (as would be the case in a normal stop situation), then you would lose access to that memory space and your sessions would not close properly.  I got around this by adding some code to ensure the controller did not close before the device actors closed.  But, this is really kludge-y.

All that bein said, the ESF is simple and provides a template for something to be improved upon.  This likely would be something that you would want to do, but rather than wrapping the class in a DVR, you might want to use something with a memory lifespan that is not directly tied to the initial calling VI.

Anyway, this is just some thing to think about.  I would be interested to hear what you ultimately go with, so keep us posted. 

Cheers, Matt

[Jeannius]

Thank you sir. The ESF will work perfect for me because my controlling actor spawn all others as nested actors. Besides I plan on logging data using the controlling actor as a central point kind of like MVC.

but yeah, will definitely check it out tomorrow. I have a feeling it's exactly what I need. Thank you

[Jeannius]

Does the ESF allows only 1 of all the subscriber to have access at a time? What happen whe 2 subscribers tried to access the shared resource?

[cirrusio]

Jeannius,

DVR access is blocking.  This would means that only one reference can have access at any time.

Getting back to the point I was trying to make - in the Actor Framework, when you shutdown, generally you send a normal stop.  In this case, what will happen is that the controller will pass the stop onto all nested actors and then shutdown.  Once the controller shuts down, you will no longer have access to the DVR and this can cause problems if you expect some clenaing up of the session to occur on shutdown.  I worked around this by having my controller wait several seconds before final shutdown.  This is not a good way to do this, but at this point, too much of my code is wrapped up in these DVRs and I have no time to refactor.  If I was to start from scratch, I might examine another way to do this.

That being said, the ESF is very nice as long as you are aware of this.

Cheers, Matt

[AristosQueue (NI)]

mtat76 -- there are two better ways to implement such clean up work.

a) [a bit hackish but clean] You can intercept the Stop Msg for your actor in Receive Message.vi and instead of handling it (which shuts everything down), begin a proper shutdown sequence. That is, you send notifications to other relevant other actors of your *intent* to stop, you wait for replies from them that they have acknowledged that intent and are done with any resources you provide, and then you send yourself a Stop message.

b) Don't send the Stop Msg in the first place -- have your system use a "Please Stop Msg" and then only send Stop to yourself after all the systems have acknowledged.  Basically, create for yourself a "kill -15" message and save the built-in Stop Msg for the "kill -9".

[cirrusio]

Thanks, AQ.  I figured there is a better work around but right now I am in a big push and the wait works (although is prone to breaking, so it needs to be clenaed up).  I will probably refactor for delivery to account for this and remove the stop and implement something like what you are suggesting.

Cheers, Matt

[Jeannius]

I have decided to go a different way, using some of the newly found knowledge about DVR and "In Place Element" structures based on my reading of ESF.

I shall detail the problem a little more so that the solution will make more sense (once I have a little more time on my hand, I also plan to maybe create a tutorial project). That is a very good tutorial for anyone doing data acquisition or communication with multiple instruments.

[cirrusio]

OK, so I have found a little time to look at this and an opportunity to build something that might work for proper shutdown.  AQ, what do you think of maintaining a list of enqueuers and then using the Handle Last Ack Core to determine who shuts down and how many nested actors still remain?  In this case, I would wait for the last nested actor to exit, and then send a normal stop to self.  Here is the code (Device Enqueuers is just a list of the enqueuers of the nested actors; seems the VI snippet barfed, so forgive the broken wires):

Anyone have any thoughts on this?

Matt

[AristosQueue (NI)]

mtat76 wrote:

AQ, what do you think of maintaining a list of enqueuers and then using the Handle Last Ack Core to determine who shuts down and how many nested actors still remain?

I think that's exactly how I would do it.