On Jul 1, 3:09 pm, Rich Hickey <richhic...@gmail.com> wrote:
[snip]
> lock architecture that is woven throughout. In fact, I think the
> possibility for knobs is a key strength of an STM. Furthermore, such
> knobs can be dynamic, allowing for applications that analyze their own
> runtime situation and adapt, in this case trading off memory for
> concurrency. Try doing that with a lock policy. (I know you are not
> advocating for locks, but Cliff was).
That sounds very interesting. Can you share the JavaOne program?
(perhaps with some text explaining the points you made :-)
[snip]
> So, certainly many of the things Cliff said are true, but are they
> negatives? You will have to understand the fundamental characteristics
> of your STM, and any knobs it provides. You will have to choose
> transaction boundaries. You will have to choose ref granularity. Ok.
> But absolutely nothing is going to make the fundamental issues of
> concurrency go away. The real question is, what facilities are
> provided for dealing with them, and how closely do they map to the
> nature of the problem? How much effort do you have to spend on
> correctness?
Yes, perhaps this is a good way of looking at it. Also I like the
analogy with GC tuning: by default it does pretty well, and in
addition you have various knobs to tune performance and other
characteristics (e.g. stop-the-world or concurrent) - and of course
you have to understand the GC to use these knobs.
[snip]
> I'll try to expand upon "adaptive history queues", and the new knobs,
> in the docs so people can better understand what they imply.
This would be really useful. In order to turn the knobs correctly we
need a more detailed understanding about the design/implementation.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
