On May 25, 8:53 pm, "Raoul Duke" <rao...@gmail.com> wrote:
> > I hope you don't wait for an answer to this (hard AI, potentially
> > impossible) problem before dipping your toes in STM - it's likely you
> > could make a significant contribution.
> it would be pretty nifty if you two had the chance to get together to
> try out & blog about Clojure STM on an Azul box :-)
That could be fun.
Towards that end, and more generally, it would be nice if there were
metrics for success other than anecdotes from the field. There should
be some meaningful problem statement STM and other solutions could
take aim at, something more real-world than the typical STM paper's
correctness test or Erlang's 'pass messages around in a circle' and
'accept connections until you die' benchmarks, and more attainable for
a new technology than the million-line systems Dr. Click and Brian
Goetz mentioned in their final Java One talk, or Erlang's nine-9s
phone switches. Then everyone could run proposed solutions on their
own 2/16/multi-hundred-processor systems and say - nope, not quite,
this works, this doesn't.
Unfortunately, describing such a problem in an architecture-neutral
way is difficult. I think there can be a certain presumption that any
concurrency solution should allow people to architect systems much as
they do now, as a graph of directly-connected mutable stateful
objects. Dropping STM (and many of the other concurrency mechanisms)
into such an architecture is likely to forever disappoint. IMO, if
you're not serious about immutability, you're likely to struggle with
concurrency.
On my side, points were taken re: transparency and control for STMs.
The Clojure STM's current architecture is certainly capable of both
better reporting and control.
So I'll be working on adding the necessary diagnostic counters, and
exposing the many aspects of the Clojure STM that could become 'knobs'
for performance tuning - timeout windows, retry counts, history cache
sizes etc. So, I have some work to do before I'd like that kind of
scrutiny :)
Rich