On Wednesday, July 18, 2012 1:20:03 AM UTC+1, Warren Lynn wrote: > > The "making progress" seems an illusion here to me. Sure, you can make > progress in one thread while another thread is taking one hour to finish > its part. But the cost is the "long" thread finally found out "oops, I have > to start over my one-hour job". > > Being lockless seems useful for certain cases (like real-time system as > mentioned in the Wikipedia article). But I still could not grasp the idea > how it can increase *real* work throughput, as the problem itself mandates > a part of the work can only be done in serial. > > Being lockless will not introduce more parallelism to an algorithm. So it will not beat Amdahl's law no matter how hard you try. In practice, because of the retries, performance will degrade to a level (sometimes much lower) which can be achieved by using locks. The point of clojure's threading support is (as I see it) is that you do not have to deal with lock hierarchies and deadlocks. On the other hand you cannot really control performance degradation in case of contention (too many retries) so in the end it is just a trade off. For some problems it is worth to make it, for other problems you are better to use locks or work queues. Hope that helps. Andrew
-- 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
