I'm familiar with what "synchronized Type foo (args)" does -- my last question was more about what aspect of a lazy seq the object with the method corresponds to. Cons cell or similar subunit? I could read half of clojure.lang, learn how all the various types of seq (Cons, LazySeq, ChunkedSeq, etc...) work under the hood, and thereby eventually figure it out, but it's probably a lot fewer man-hours of work for me to ask someone who's already intimately familiar with that codebase and for him to answer...
On Mon, Jun 24, 2013 at 10:32 PM, Timothy Baldridge <tbaldri...@gmail.com>wrote: > Reading the LazySeq.java file should make this all clear, but yes, no race > conditions. > > > https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 > > Synchronized methods basically lock the current instance of the object > while the method runs, so it is impossible for two threads to execute the > lazy seq fn at the same time. > > Timothy > > > On Mon, Jun 24, 2013 at 4:17 PM, Cedric Greevey <cgree...@gmail.com>wrote: > >> Ah, thanks. The locking granularity is local to the cons cell (or >> analogue; first/rest pair) being realized, I hope? So one thread actually >> calculates an element and neither call returns until it's calculated, and >> then both promptly return the calculated value, but threads realizing other >> lazy seqs or crawling along earlier parts of the same one don't get >> blocked? (And given they can share tails, how would "same one" even be >> defined anyway?) >> >> >> On Mon, Jun 24, 2013 at 5:56 PM, Nicola Mometto <brobro...@gmail.com>wrote: >> >>> >>> Realizing a lazy-seq is done through a synchronized method see: >>> >>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/LazySeq.java#L37 >>> >>> No race conditions. >>> >>> Cedric Greevey writes: >>> >>> > What, precisely, happens if two threads sharing a reference to a single >>> > lazy sequence try to realize the same element at the same time? If the >>> > sequence is completely pure and deterministic, so any attempt to >>> realize a >>> > particular element will produce a single particular value consistently >>> > (unlike, say, (repeatedly rand) or a file-seq where relevant parts of >>> the >>> > filesystem are being concurrently modified), is the worst-case scenario >>> > that the two threads will redundantly perform the same calculation, >>> with no >>> > effect other than a minor hit to performance and, in particular, no >>> effect >>> > on the program semantics? >>> > >>> > -- >>> >>> -- >>> -- >>> 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/groups/opt_out. >>> >>> >>> >> -- >> -- >> 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/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > -- > 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/groups/opt_out. > > > -- -- 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/groups/opt_out.
