Menu
▾
▴
Re: [Repast-developer] DataRecorder and thread saftey
|
From: Nick C. <nic...@ve...> - 2003-01-02 19:13:33
|
Hi, Its funny because it just these kinds of dependencies that Tom and I have been removing of the last couple of days. So, I guess we are in practical agreement. This is a necessarily incremental process. Its important that we don't frustrate too many users and leave them behind otherwise the whole thing is pointless. The current refactoring of DataRecorder is an example of how I'd like things to work. It should only depend on the IController and SimModel interfaces. It should work in repast's gui, batch and distributed batch contexts. It will be a proxy for LocalRecorder (gui and batch local recording) and DistributedBatchRecorder and conform to a Recorder interface. I get lots of questions of the kind "what class should I use to ...", and I know that having a Recorder Interface with various implementors for different contexts will not eliminate the question w/r to recording data. In fact, having to pick among them would make matters worse from a typical user point of view. Users often ask me what sort of java collections to use and having a nice List Interface etc., doesn't help them decide among Vector, ArrayList, LinkedList and so on. The fact that they can be treated all as Lists is no help. In short, I'd like to provide default canonical way of doing things while allowing the kind of freedom you want. I think refactoring to provide a clearer more coherent API will help to do this, but it won't get us there entirely. This all is an expression of the tension between repast as a kind of quasi-application and as a framework. anyway thanks for the comments, Nick On Thu, 2003-01-02 at 13:31, Mark R. Diggory wrote: > IMHO (or my $0.02), > > I think your risking a sort of situation where, by not working towards > an organized API with well defined Interfaces, you risk creating too > many dependencies in the codebase. You risk actually confusing your > users by providing too many methods/constructors for a particular class > (Schedule as an example of this), this draws up a situation where your > users/model developers actually can't get an acurate mental model of the > API or the capabilites of a class within the API because the classes > either "do too much" or "do too little". I've spent much time leafing > through code trying to develop an acurate mental model of the packages. > I think its this confusion which stop the users from understanding what > they can really do in the Repast Simulation Framework. You, in turn to > compensate for this, attempt to make "more" options available to the > user in the base classes of Repast, which doesn't really solve the > problem of the confusion the user is experiencing. I believe, that a > well organized API is the only way to solve such problems, its the only > sound strategy that will lead developers keeping control over thier > development and as a tool to expose the capabilites of the > package/framework to the users. Ideally, if you want "pluggable style" > components in your framework (like your heading towards with Evolver) > then you need to consider the organization of your API. > > I remember a comment you made earlier about trying to retain backward > compatability so that old models written against earlier versions of the > API could still run against new versions of the API. This is another > areana where one has to be very alert too code bloating. Having to > "retain" an old method because it was possibly called by an older model, > but which you wouldn't consider a valuble part of the API to be used by > newer models can get problematic if it happens alot. Eventually you > would have to consider using deprication to remove such methods and get > them out of your api so that you can move forward in its development an > let go of the older design. I really don't think its the case that you > will really loose users if you have a sound and well defined goal for > the development that occurs over many releases and provides many > opportunities to alert the user to deprications and removals that are > coming. Giving the users opportunities for input into the overall design > will definitly keep their interest in future releases of Repast. It is > always the case that a user could install an older version of repast for > which their model was designed in, but with well documented and timed > changes in the API, making the minor modifications required to adopt > their model to the new API are easy tasks that will actually excite and > inspire the user when they reallize the added benifits. > > I agree that I am looking at the package with a great deal of > "developer" experience and as an API that I want to utilize in a > programming environment. From my experience with Java and picking up > packages and using/learning them (across many releases of the package), > I do see this as the ultimate path to go on. I think a "well designed" > API is really the foundation for a Framework that is simple to use. A > framework without a well defined API has the danger of following a path > of development where the ability to track dependencies becomes too > complicated (think of Netscape before Mozilla). The code can become too > confusing to maintain. While the Repast codebase has a ways to go before > it reaches this extreme, you have an opportunity to avoid going down > this path by refactoring the API and stablizing the Implementation > behind solidly defined Interfaces. > > Ok, maybe that was $0.03, > Mark > > Nick Collier wrote: > > >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 |
