@Master, write-read is fine, since the pending read could commit before the write commits. Check out case 3 on slide 50
shiyqw
@lya, So why should we forbidden read-write but not write-read?
lya
@shiyqw Take the cases 2 and 3 on slide 50 as examples. Case 2 is a read-write, when T0 commits, we need to abort T1, since T1 has read the original value of A. That is, if we do not abort T1, and T1 commits later, we can see that T1 uses a stall value of A, which is modified by T0 before T1 commits. It violates the serializability of transactions. However, for case 3, which is a write-read, it does not hurt if we do not abort T1 when T0 commit. The reasoning is that T0 commits before T1, so we could order T0 and T1 on a single timeline without violating the serializability.
sushi
@lya, in case 3 on slide 48, the write-after-read conflict is detected, and read transaction is aborted since the write has higher priority. So I think it's depending on the detection principle.
apr
Am I right in saying that pessimistic conflict detection is only required for eager versioning, since only in eager versioning are the changes visible to other threads which are potentially executing transactions? If I am right, in lazy versioning, conflict detection can be checked only during the commit step so other pending transactions can be aborted in order to prevent violation of serialization property.
EDIT: I understand now, that lazy versioning with pessimistic detection is helpful, since then you will be able to abort much before committing helping save cycles which would definitely still be wasted.
Also, one more point that I'd like to add is that, when a processor implements transactions using lazy versioning, then, when it does a read of a memory address that is already in it's write set, it would need to apply the changes in it's write buffer to maintain the basic instruction stream order effect.
Why write-read conflict isn't listed here?
@Master, write-read is fine, since the pending read could commit before the write commits. Check out case 3 on slide 50
@lya, So why should we forbidden read-write but not write-read?
@shiyqw Take the cases 2 and 3 on slide 50 as examples. Case 2 is a read-write, when
T0commits, we need to abortT1, sinceT1has read the original value of A. That is, if we do not abortT1, andT1commits later, we can see thatT1uses a stall value of A, which is modified byT0beforeT1commits. It violates the serializability of transactions. However, for case 3, which is a write-read, it does not hurt if we do not abortT1whenT0commit. The reasoning is thatT0commits beforeT1, so we could orderT0andT1on a single timeline without violating the serializability.@lya, in case 3 on slide 48, the write-after-read conflict is detected, and read transaction is aborted since the write has higher priority. So I think it's depending on the detection principle.
Am I right in saying that pessimistic conflict detection is only required for eager versioning, since only in eager versioning are the changes visible to other threads which are potentially executing transactions? If I am right, in lazy versioning, conflict detection can be checked only during the commit step so other pending transactions can be aborted in order to prevent violation of serialization property. EDIT: I understand now, that lazy versioning with pessimistic detection is helpful, since then you will be able to abort much before committing helping save cycles which would definitely still be wasted.
Also, one more point that I'd like to add is that, when a processor implements transactions using lazy versioning, then, when it does a read of a memory address that is already in it's write set, it would need to apply the changes in it's write buffer to maintain the basic instruction stream order effect.