On Mon, 2009-03-23 at 14:49 -0500, Cosmin Stejerean wrote:
>
>
> The fact that B is tried once concurrently with A, and is then aborted
> and retried is in my opinion the same as transaction B being stuck
> waiting on a lock while A is being processed, but I can see how trying
> B concurrently with A the first time might waste more resources, and
> that perhaps for certain applications it locks might have better
> performance.
>
Coming from years of intensive use of libthread, if I use it as a
comparison basis, a mutex waiting for a resource access to be granted
essentially spins.... waiting. Your thread is not doing anything useful.
Of course the spinning itself consumes CPU cycles...
Assuming you need to lock several resources, you may wait a significant
amount of time getting each mutex on
each resource AND the more resources you have to lock (the more complex
is your transaction),
the greater your dead lock chances are as concurrency increases.
If you hit a deadlock situation in a concurrent application written in
the usual libthread model, what are your options ?
Abort or ... retry on behalf of the user/event/whatever started the
transaction.
Now would you rather do this yourself or have a model that takes care of
that for you ?
Guess what, I prefer someone else to deal with this transparently
Clojure has a big advantages over the classical libthread model:
a) It makes everything immutable by default. You do not have to care
about the whole universe, just about the
stuff your transaction alters. Less bugs to discover, simpler STM
implementation.
Other languages look like single-legged runners...
b) It's it's clear in the code which resources are part of a transaction
and it allows you finer control on them. Changing stuff
is a lot simpler. Compared that with changing the granularity level
of your locks when using libthread or even in Java...
c) You are isolated from the code that deals with contention, dead
locks, restarts, ... The implementation can change
to accommodate different environmental conditions while keeping your
code sane.
You have two choices, the empirical approach which I went through and
with some experience you eventually learn the pitfalls
OR you use a "canned" approach which removes from you all these
concerns.
Which one will be more efficient with the hardware ? These days we have
much more powerful hardware than in the 1980/1990s.
In these times we had to be very careful about resource usage and code
was hand crafted very carefully.
We had 2/4/6 processors SMP machines and we were already facing
concurrency problems already with the libthread model.
The absence of a simple concurrency model had a severe impact for years
on our ability to spit out concurrent applications.
Too complex for the average programmer, hard to test, ...
The disproportion of the number of concurrent applications versus the
single threaded ones did not allow
us to learn much about scaling to environments with hundreds of CPUs.
It's been done for some mathematical models and other
bleeding edge applications but these are in very narrow application
domains.
What if STM was "waisting" cycles given the hardware power we have
today ? What if each transaction had to be retried twice ?
What if for some application concurrency situations there was a glass
ceiling that was preventing us from scaling above 100 CPUs ?
Would that be a hindrance if concurrent applications become common
because of a simpler model ?
I do not think so, the implementations could help with these problems.
You should have the ability to tune the concurrency outside
of your application. Better implementations will be created over time.
It's a bit like garbage collectors, they have existed for a long time
and have been improved over several iterations.
Having a simpler model is essential before anything else can be done.
>
> I can imagine how in certain situations a profile mode where Clojure
> keeps track of transaction retries, and maybe even the reason why they
> happened might be useful.
>
>
That kind of tool should become as common as today's profiler over time.
Frankly, I would not be too much concerned with the efficiency of STM
today and all the discussions you can read about it
on the Web. Without real complex concurrent application experience
written with STM and Clojure, speculations about behaviours
are as reliable as your daily horoscope.
Clojure is a key factor here, I do not think you can compare other STM
applications written in other languages
with Clojure equivalents. It's looks much more complex to implement and
use STM in other languages because of the
lack of the default immutability rule that Clojure provides.
I apologize to those who believe very hard in their daily
horoscope :))))
Luc
> --
> Cosmin Stejerean
> http://offbytwo.com
>
>
> >
Luc Préfontaine
Armageddon was yesterday, today we have a real problem...
--~--~---------~--~----~------------~-------~--~----~
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
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
-~----------~----~----~----~------~----~------~--~---
