<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Your comparison of normal threading and STM is interesting. You say: "with STM you could just read a snapshot of the data". This implies that an immutable snapshot of the data exists, which implies some sort of copy-on-write where the simulation copies the data every time it changes. It won't stop the simulation in order to access the data, but it'll likely make it perform slower with all those allocations. It's really a tradeoff between data immutability and mutability. To access mutable data, you need a lock; not so for immutable data.<br>
<br>
So while I agree that supporting transactions would be great, I'm not sure how great it'd be for your use case. Especially since if you allocate a lot of memory for immutable data, the GC will kick in more often and lock the world anyway.<br>
<br>
Message passing, where you could subscribe and unsubscribe to various parts of the simulation data, could be a good solution because then the simulation thread has to create copies of only what has been requested.<br>
<br></blockquote><div><br>Well, in case you don't care that all the snapshot shows the same time step for all agents, there won't be a big performance impact.<br><br>On the other hand, I think a nice combination to look at is Clojure's concurrency model:<br>
<br>"While <a class="wiki_link" href="http://clojure.org/Vars">Vars</a> ensure safe use of mutable storage locations via thread <em>isolation</em>, transactional references (Refs) ensure safe <em>shared</em> use of mutable storage locations via a <a class="wiki_link_ext" href="http://en.wikipedia.org/wiki/Software_transactional_memory" rel="nofollow">software transactional memory</a>
(STM) system. Refs are bound to a single storage location for their
lifetime, and only allow mutation of that location to occur within a
transaction."<br><br>From <a href="http://clojure.org/refs">http://clojure.org/refs</a><br><br>However, I believe a similar effect can be achieve with message passing.<br><br>[At this point I received Andrei's post]. It's right to concentrate on message passing then. Just wanted to bring it into discussion, and know some points of view.<br>
<br>Best Regards,<br><br>Álvaro Castro-Castilla<br><br><br></div></div>