On Thursday 11 June 2009, Ketil Malde wrote:
Hi,
Browsing LWN, I ran across this comment:
http://lwn.net/Articles/336039/
The author makes a bunch of unsubstantiated claims about STM, namely
that all implementations use locking under the hood, and that STM can
live- and deadlock. I've
Hi,
Browsing LWN, I ran across this comment:
http://lwn.net/Articles/336039/
The author makes a bunch of unsubstantiated claims about STM, namely
that all implementations use locking under the hood, and that STM can
live- and deadlock. I've seen a lot of similar sentiments in other
places as
On Thu, Jun 11, 2009 at 2:30 AM, Ketil Malde ke...@malde.org wrote:
Hi,
Browsing LWN, I ran across this comment:
http://lwn.net/Articles/336039/
The author makes a bunch of unsubstantiated claims about STM, namely
that all implementations use locking under the hood, and that STM can
Ketil Malde wrote:
Hi,
Browsing LWN, I ran across this comment:
http://lwn.net/Articles/336039/
The author makes a bunch of unsubstantiated claims about STM, namely
that all implementations use locking under the hood, and that STM can
live- and deadlock. I've seen a lot of similar sentiments
Neil Brown nc...@kent.ac.uk writes:
I think there needs to be some differentiation here between the
implementation of STM, and the programmer's use of STM.
The implementation of STM does effectively use locks (from memory,
it's this paper that explains it:
Ignoring the paper in the interest
Ketil Malde wrote:
So the naïve attempt at doing this would be something like:
thread = do
-- grab lock 1
t - readTVar lock
when t retry
writeTVar lock True
-- grab lock 2
t2 - readTVar lock2
when t2 retry writeTVar
writeTVar
On Thu, Jun 11, 2009 at 4:38 AM, Ketil Maldeke...@malde.org wrote:
Ignoring the paper in the interest of laz...expedience, I guess the
crucial part is committing the transactions - you'd either need locks
or to single-thread the committing.
It's possible to single-thread the commit without
