Is the cost of aborting an atomic region proportional to the instructions in the atomic region? If so is it always a good practice to keep atomic regions small?

Is the abort here just means restart immediately?

Yes, we abort because the value that we read has been changed, so we need to repeat the cycle of instructions to re read the value.

I am also curious about if we want to have smaller transactional segments to potentially reduce the cost of restarts. I guess one downside is that you need increased overhead with setting up transactional logs, not too sure.

@kai I would assume so. In the abort, we have to restart all operations. Having a large atomic block abort means more operations we would need to redo, which increases the overall time cost of the abort.

So in STM, is the idea that you'd need some sort of runtime (maybe like the JVM) to determine when a conflict arises, such that you could abort the conflicting transaction?

Would it at all be possible to detect conflicts at compile time - or is it only a runtime concept?

Can someone please explain: Why does X2 stall when executing t2=bar.y ? Where did we learn that reading transactions must stall if the data that is read is locked by some other transaction? Shouldn't this be eager read to get the data currently present in bar.y?

@pranil. I believe that TXN 2 must stall when executing t2 = bar.y because we haven't committed the value of bar.y yet.

Think about what might happen if bar.y has written (no stalls) in TXN 2, but TXN 1 needed to roll back; we'd have an incorrect value for bar.y.

At least, that's how I'm interpreting it.

I still have two questions: 1) Why are there no local timestamps, isn't the timestamp for each object is a local timestamp? 2) when X2 executes t2 = bar.y, why does it wait? Shouldn't it abort according to the read-set validation mentioned in slide_19? Or is this another STM algorithm?