John Warner Backus

[Sean Kelly]

Pragma wrote:
> 
> "Transactions are the only plausible solution to concurrent mutable 
> statue."

I'm not sure I agree.  Many of the most common transactional processes 
work much like mutexes.  In SQL, for example, data affected by a 
transaction is locked (typically at row, page, or table granularity) in 
much the same way as obtaining locks on mutexes protecting data. 
Deadlocks are quite possible, and before the era of automatic deadlock 
resolution, froze the DB indefinitely.

The new concept of transactional memory turns this idea on its head by 
cloning affected data instead of locking it, and mutating the clones. 
Committing a transaction is therefore accomplished by comparing the 
original version of all affected data with the current version of the 
affected data, and if they match, the clones are substituted.  If they 
don't match however, the entire transaction is rolled back and retried. 
  The result is that large transactions are slow and require an 
unbounded amount of memory (because of the cloning), and no guarantee of 
progress is provided, because success ultimately relies on a race condition.

That said, there have been proposals to add a transactional memory 
feature to hardware, and I think this is actually a good idea.  The 
existing hardware-based solutions are typically limited to updating no 
more than 4-8 bytes of contiguous data, while transactional memory would 
allow for additional flexibility.  I've seen implementations of 
lock-free binary trees based on this concept, and I'm not aware of 
anything comparable without it.  Progress guarantees are less of an 
issue as well because hardware-level transactions will typically be very 
small.

> D shines in a few of these areas, but needs library support for 
> transactional memory, better concurrency support and constructs, 
> something like a well-coded numerics library (true integers, etc), and 
> something resembling compile-time iterator/bounds checking to fit the 
> bill. :(

I'd add something like CSP to the category of "better concurrency 
support."  And I agree with the rest.


Sean