Some Haskell compilers also implement software transactional memory: Haskell STM.
aznshodan
Why is Eager and Optimistic not practical?
subliminal
I'm ripping this off straight from Austen McDonald's PhD dissertation (I had read parts of it a couple of years ago, it's really informative):
Eager-Optimistic (EO) is not a logical choice for HTM (Hardware TM) systems: since new transactional versions are written in-place, other transactions have no choice but to notice conflicts as they occur (i.e., as cache misses occur). But since EO waits until commit time to detect conflicts, those transactions become “zombies,” continuing to execute, wasting resources, yet are doomed to abort.
Some Software TM systems implement it, though.
aznshodan
What is a difference between Software TM and Hardware TM? I thought TM was handled by the hardware?
gryffolyon
@aznshodan Yes TM is mostly implemented in hardware. While there is active research going on Software TM too, I am not aware of practical implementations. I am curious to know more about it too. Actually wiki has some good stuff on it SoftwareTM
Kapteyn
It doesn't seem practical to implement eager + optimistic in HW.
Specifically I'm thinking of the following scenario:
T2 Writes A
T1 Reads A
T1 Writes B
T1 attempts to commit
Had this been a lazy versioning system, when T1 goes to commit, it can commit without having to abort T2's transaction since we can lay T2's transaction after T1's on a timeline.
However, since this is eager versioning, we would actually have to abort the transaction that is about to commit, i.e. T1's transaction, because T1 reads the value of A written by T2, which means on the timeline, T2's transaction has to commit before T1's transaction. But this runs counter to the whole point of optimistic detection, which gives priority to the committing thread, so that we always make forward progress.
Basically I think the problem with eager versioning + optimistic is that other threads can see the changes a given thread has made before it actually commits its transaction. Furthermore it seems like with eager versioning, if a thread ever has to abort it's transaction, all other threads that read any of the addresses that the aborting transaction wrote to must abort as well.
Some Haskell compilers also implement software transactional memory: Haskell STM.
Why is Eager and Optimistic not practical?
I'm ripping this off straight from Austen McDonald's PhD dissertation (I had read parts of it a couple of years ago, it's really informative):
Eager-Optimistic (EO) is not a logical choice for HTM (Hardware TM) systems: since new transactional versions are written in-place, other transactions have no choice but to notice conflicts as they occur (i.e., as cache misses occur). But since EO waits until commit time to detect conflicts, those transactions become “zombies,” continuing to execute, wasting resources, yet are doomed to abort.
Some Software TM systems implement it, though.
What is a difference between Software TM and Hardware TM? I thought TM was handled by the hardware?
@aznshodan Yes TM is mostly implemented in hardware. While there is active research going on Software TM too, I am not aware of practical implementations. I am curious to know more about it too. Actually wiki has some good stuff on it
SoftwareTM
It doesn't seem practical to implement eager + optimistic in HW.
Specifically I'm thinking of the following scenario:
T2 Writes A
T1 Reads A
T1 Writes B
T1 attempts to commit
Had this been a lazy versioning system, when T1 goes to commit, it can commit without having to abort T2's transaction since we can lay T2's transaction after T1's on a timeline.
However, since this is eager versioning, we would actually have to abort the transaction that is about to commit, i.e. T1's transaction, because T1 reads the value of A written by T2, which means on the timeline, T2's transaction has to commit before T1's transaction. But this runs counter to the whole point of optimistic detection, which gives priority to the committing thread, so that we always make forward progress.
Basically I think the problem with eager versioning + optimistic is that other threads can see the changes a given thread has made before it actually commits its transaction. Furthermore it seems like with eager versioning, if a thread ever has to abort it's transaction, all other threads that read any of the addresses that the aborting transaction wrote to must abort as well.