Re: [Repast-developer] DataRecorder and thread saftey

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

Hi,

I agree that a Recorder interface might be useful, but its important to
think of repast as more than a framework of pieces for simulations. The
idea is that, although we are trying to make repast as "open" as
possible, we want to provide support for three kinds of simulations:
gui, batch, and distributed batch. In order to allow users to do this
easily and not shoot themselves in the foot, somethings are more tightly
bound to each other than they otherwise would be if we were just
providing a framework. In this case, the idea is that a call to 

new DataRecorder(...)

will create a data recorder appropriate for gui, batch and distributed
batch simulations depending on the running context. The point being that
we want this to be as easy for users as possible. We want to allow you
to create other kinds of recorders, but DataRecorder is written to
support our gui, batch and soon distributed batch capabilities. That
said, the various pieces that make up a data recorder, the data sources
etc. are still open to you. Its just the writing and the actual
extraction of data from the sources that one would need to code.

What I'm trying to say is that we need to strike a balance between
letting experienced programmers use repast as something close to a
component framework for developing simulations, and allowing
inexperienced users to develop _repast_ gui, batch, or distributed batch
simulations. Hope this makes sense.

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