4 ms·
That's not how TM is supposed to work; it should not be possible for one atomic block to observe an uncommitted write of another atomic block. It must act as if
by continuational 11y ago
That's not how TM is supposed to work; it should not be possible for one atomic block to observe an uncommitted write of another atomic block. It must act as if each atomic block acquires a single global lock, executes, and then releases the lock so that other atomic blocks may execute. The challenge is to emulate this without actually using a single global lock.
- signa11 11y ago> That's not how TM is supposed to work; it should not be possible for one atomic block to observe an uncommitted write of another atomic block. well, transactions need to be atomic w.r.t each other, but what about their relationship to non-transactional code ? it might appear that this is just an 'implementation' detail, but, programs can contain unprotected references to shared variables (i.e., outside transactions) without creating malignant data races. so, both transactional and non-transactional code can refer to the same data. this is where the notion of strong and weak atomicity comes from, and which is what the pseudo code was trying (probably unsuccessfully) to show.