The acronym ACID in database describes desirable properties for transactions (changes to a database, typically):
Atomic = all changes are made (commit), or none (rollback).
Consistent = transaction won't violate declared system integrity constraints
Isolated = results independent of concurrent transactions.
Durable = committed changes survive various classes of hardware failure.
cwchang
One question. Transactional memory can ensure that if the program crashes, either all or none of the manipulation will be applied to the memory. However, what if the "crash" happens during the "process of ensuring transaction"? I mean, how can we be sure that the "transactional" part of the program will not crash?
To be more clear, take the versioning as example in page 44. What if crash happens when we trying to apply the content in write buffer to memory (lazy versioning)?
lya
@cwchang There are two possible ways to implement the multi-write atomicity even if the program crashes. The first one is write-ahead logging. In this case, all changes will be recorded to a log before the real changes happen. Therefore, if the program crashes halfway, recovery could be performed based on the log. Another one is shadow paging. In the example on slide 44, instead of copying the data "15", we could modify the pointer directly, so that the change is guaranteed to be atomic.
The acronym ACID in database describes desirable properties for transactions (changes to a database, typically):
Atomic = all changes are made (commit), or none (rollback).
Consistent = transaction won't violate declared system integrity constraints
Isolated = results independent of concurrent transactions.
Durable = committed changes survive various classes of hardware failure.
One question. Transactional memory can ensure that if the program crashes, either all or none of the manipulation will be applied to the memory. However, what if the "crash" happens during the "process of ensuring transaction"? I mean, how can we be sure that the "transactional" part of the program will not crash?
To be more clear, take the versioning as example in page 44. What if crash happens when we trying to apply the content in write buffer to memory (lazy versioning)?
@cwchang There are two possible ways to implement the multi-write atomicity even if the program crashes. The first one is write-ahead logging. In this case, all changes will be recorded to a log before the real changes happen. Therefore, if the program crashes halfway, recovery could be performed based on the log. Another one is shadow paging. In the example on slide 44, instead of copying the data "15", we could modify the pointer directly, so that the change is guaranteed to be atomic.