Re: [Repast-developer] DataRecorder and thread saftey

[Mark R. D. <mdi...@la...>]

Thank you, I value your saying that. I enjoy having the opportunity to 
provide input on the packages I work with, whatever your decision about 
the path of development. Besides, if I need something a certain way, and 
your development isn't heading that way, then I just build it myself. ;-)

We all have different viewpoints and opinions, that what makes this all 
so interesting!

-Mark

Nick Collier wrote:

>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
>>    
>>