Re: [Repast-developer] DataRecorder and thread saftey

[Nick C. <nic...@ve...>]

Hi,

Just in case the tone of my last email may have indicated otherwise, I
and Tom as well really appreciate your comments. The work I did this
morning is the direct result of the IController refactoring so we are
trying to strike an appropriate balance.

Nick

On Thu, 2003-01-02 at 11:46, Mark R. Diggory wrote:
> I was actually working one the idea of having a "DataRecorder" available 
> across Simulation Threads. The idea is that since I've moved my batch 
> processing up and out of the Repast Controller API, I'm now handing an 
> already existing instance of a my Recording Class into the 
> Controller/Model pair I'm runinng. I havn't encountered an issue where 
> threading would be a problem, but where I'm heading could invlove 
> multiple simulations running at the same time on different threads, 
> thread saftey could be benificial. Sadly, I ended up just writing a 
> class BatchRecorder that wraps a FileWriter, not that its a 
> "DataRecorder". While I understand the concepts behind "DataRecorder" I 
> wanted a little more control over the header and record layout than I 
> could get in the DataRecorder, so I ended up rolling my own.
> 
> Thomas R. Howe wrote:
> 
> >Funny you should ask, because I'm facing the same issue as I am writing
> >the DistributedDataRecorder.  The classes are not thread safe.  I need
> >to warn you, As I'm writing the distributed stuff, I will probably turn
> >DataRecorder into a Proxy for either a distributed or a local
> >DataRecorder.  This won't affect most people, but perhaps it will for
> >what you are doing.
> >  
> >
> Not to sound like an "Interface junkie" but would it be good to place 
> the DataRecorder behind a "Recorder" interface. Instead of thinking of 
>  it as a proxy, produce separate DistributedDataRecorder and 
> DataRecorder implementations of the Recorder Interface? Then The 
> DataRecorder can stay in its current state and New Implementations (like 
> DistributedDataRecorder) can be created by developers. 
> 
> I guess in the case where a Model might have a "Recorders" collection 
> that any recorder can be added into, then data collection just becomes 
> an issue of calling Recorder.record()/Recorder.writeToFile() on the 
> objects in the collection.
> 
> I.E.
> 
> List recorders = new ArrayList();
> 
> recorders.add(new DataRecorder(...));
> recorders.add(new DistributedDataRecorder(...));
> 
> ActionGroup group = new ActionGroup(ActionGroup.SEQUENTIAL);
> group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> , "record");
> group.createActionForEach(recorders, uchicago.src.sim.analysis.Recorder 
> , "writeToFile");
> 
> schedule.scheduleActionBeginning(0.0,group);
> 
> -Mark
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net