It doesn't need to be simultaneous within the actual update function (the function that's passed in to swap!), it needs to be simultaneous just as far as the atom state-change is concerned. A faster update function means less contention and restarts.
On Fri, Mar 21, 2014 at 4:13 PM, Jacob Goodson <submissionfight...@gmx.com>wrote: > If they were nested what would I use to update them simultaneously? > Futures, then roll a loop that would wait till both are realized? > > > On Friday, March 21, 2014 4:00:03 PM UTC-4, Ben Mabey wrote: > >> For coordination of this type you could either a) use refs and the STM >> or b) put them in the same nested datastructure and put them both in an >> atom. The latter approach is what I would recommend and what people >> generally tend to do. If you go down this route you end up with the entire >> state of your game in a single atom. The tradeoffs is that you loose the >> ability to observe certain changes at a granular layer and you drive the >> contention to a single point (which has been discussed recently on another >> thread). On the flip side you end up with a single value that represents >> your application's state that is easy to work with. >> >> On 3/21/14, 1:42 PM, Jacob Goodson wrote: >> >> Say I have two data structures.. >> >> enemies >> bullets >> >> I want to update them like so... >> >> (some-game-loop >> (update enemies) >> (update bullets)) >> >> If I wanted to make sure that both structures were getting updated at the >> same time instead of >> >> enemies and then bullets; would I use refs here or would I use something >> else? What if there >> >> were many more structures that I wanted to update asynchronously like >> this? Thanks clojurians! >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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+u...@googlegroups.com >> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
