If you have a fixed geometry of cells, it is quite easy to have one ref per cell. Which reduce a lot of contention.
For example, on a grid where ant can go instead of representing the world as a ref to a matrix, you can represent the world as a matrix of refs. Those refs can then be update concurrently. Provided there are a lot of cells and not too much contention, iti should work well. On Sun, Sep 19, 2010 at 11:01 PM, Hozumi <fat...@googlemail.com> wrote: > Hi. > I posted following question. > > The more threads that changes the Clojure's ref are, the more does the > rate of retries per threads rise? > http://stackoverflow.com/questions/3746893/the-more-threads-that-changes-the-clojures-ref-are-the-more-does-the-rate-of-re > > I think increasing retries in O(thread^2) means that refs should not > be used to store the data that is aletered by too many threads like > big ant colony map or newral network nodes. > If modifying the data by too many threads is planned, instead of refs, > are agents best way to store it? > Any other solution? > > Thanks. > Takahiro Hozumi > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
