As was described in a "Software Engineering Radio" podcast on transactional memory, there are many parallels between garbage collection and transactional memory. Some parallels that aren't in place yet though include:
1) There are tools to measure the impact of GC on runs of an application, but we don't yet have similar tools for TM. 2) The operation of GC can be tuned through command-line options, but no such options are available yet for TM. I don't know if these are really needed for TM, but I suspect they would be useful and would at least make people feel more comfortable about building large applications using TM. I believe everything you say about programming with STM being much easier than programming with locks. My concern is only about performance measurement and tuning, either through options or code refactoring. On Mon, Mar 23, 2009 at 6:27 PM, Luc Prefontaine <lprefonta...@softaddicts.ca> wrote: > > 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 :)))) -- R. Mark Volkmann Object Computing, Inc. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
