On Nov 4, 3:47 am, "Christian Vest Hansen" <[EMAIL PROTECTED]>
wrote:
> Just reading through the first CACM article, they raise a number of
> issues that I think are more addressed in Clojure than they give
> credit to TMs in general based on whatever implementation they were
> investigating.
>
> I present my feeble attempt to join the TM debate:
>
> > TM introduces a variety of programming issues that
> > are not present in lock-basedmutual exclusion.
> > For example, semantics are muddled by:
> > * Interaction with non-transactional codes,
> > including access to shared data from outside
> > of a transaction (tolerating weak atomicity)
> > and the use of locks inside a transaction
> > (breaking isolation to make locking operations
> > visible outside transactions);
>
> The referencing part is at least clearly defined: outside a
> transaction, the refs are read-only.
>
> Locking is a different beast. While true that it is a side-effect that
> will creep to the outside world, I don't see how a lock inside a
> transaction is bad in any way that a lock outside a transaction is
> not. (But they might have yet to tell me since still not through with
> the paper.)
>
> > * Exceptions and serializability: how to handle
> > exceptions and propagate consistent exception
> > information from within a transactional context,
> > and how to guarantee that transactional execution
> > respects a correct ordering of operations;
>
> A consistent snapshot of the world is presented inside a transaction.
> Exceptions and serialization will be based on that world view.
>
> I don't get what they mean by correct ordering of operations. Ordering
> inside a transaction would matter just as much as it does in a
> single-threaded scenario, would it not?
>
> > * Interaction with code that cannot be
> > transactionalized, due to either communication
> > with other threads or a requirement barring
> > speculation;
>
> Just don't do that. Transactions are not a silver bullet. Use an agent
> instead.
>
> > * Livelock, or the system guarantee that all
> > transactions make progress even in the
> > presence of conflicts.
>
> True, TMs don't solve this for you. Just like locking doesn't solve
> deadlocks for you.
>
> A key assumption of the paper seems to be that TMs are the solution to
> all things concurrency. But perhaps this is exactly the myth they are
> trying to debunk?
>
Exactly my problem with these articles - they sum up to "STM is bad
because it's not a panacea".
I don't actually see many people claiming it is.
Furthermore, STM is not a single thing and more than is GC. There will
be many flavors with different tradeoffs and properties.
> My view is that TMs are another tool in the box, just like CAS, locks,
> agents, volatile, thread-locals, immutables, atomics and all the rest
> of java.util.concurrent.
Precisely.
RIch
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
