What is the good practice of maintaining global object and it's data.

[Snipper]

Hello,Everybody. I  have a self-defined report toolset. and it have to be added "file header" before I append my report data. It means I have to check and get a File Header Flag(global object)'s data and decide whether to write. It's OK by tranditional QMH method. but I encounter problem by AF.I have tried a solution by AF method, But I think this solution is not elegant enough, so I post my question here.

I make a simple explanation to my current solution.I regard a config.ini file as the global object, and   AAA and AAB are different ''controller', If I Run Test AAA.vi, It will remove "config.ini" file(destroy object), while Running Test AAB.vi do not remove the file.,Running AAA's and AAB's Actor Core.vi will check and append file(HH_MM_SS.log) and set Flags by updating config.ini file.   So now If you delete Config.ini and log file first, then Run Test AAA.vi then Test AAB.vi    VS       TestAAB.vi then Test AAA.vi,  you will get different log content.

[AristosQueue (NI)]

I do not have time today to look at your project or give you a deailed answer. Sorry -- too many other things going on. But the short answer is this: The easiest way to handle global data is to not have global data. Have one actor read the data (config file) and then send a message out to the other actors with that data in it. The other actors then store their own copy of the data within themselves and have it available to check. If the value(s) change, whichever actor caused or detected the change sends an update message out to the other actors. You don't have to send the whole config file to every actor -- if you've organized your actor tree well, you should be able to be selective and only send the data that the specific actor needs.

[drjdpowell]

The problems of multiple processes accessing the same reference is a big motivation behind the idea of ‘Actors’.  Actors solve the problem by never sharing references.  Each reference is private to one actor and all other processes must interact with that reference via messages to the owning actor.   

Now, you can break the sharing reference rule (and I do), but not without considering the reasoning for the rule.  For example, I have an application of several actors (not AF, but similar) where there is a single common ini config file.  I could have made a “Config” actor, but I didn’t spend the time.  Instead, each actor has a separate section of the ini file, so they are essentially independent section references.  There was one case where one actor needed to read part of another actor’s section, and that is exactly the kind of thing that could cause problems.  However, the two actors in question never actually run at the same time (they were ‘Test Editor' and ‘Test Executive’ actors that by design only have one in existence at a time).  So I didn't have the problems of multiple processes accessing the same by-reference data.

[cirrusio]

I know this is a late reply and it is specific to drjdpowell's comment, but I thought I might throw this in - in the case of the config file having to be accessed by multiple actors, have you considered using the extensible session framework (ESF) that was put out there by David Staab.  This should overcome the need for a config file actor (and it is a cool idea that hasn't seemed to see a lot of daylight).