Could processor 3 possibly execute before p2 in this case so that it wouldn't be until the next row in the table that t4 would be restarted?

I am wondering the same question. In lecture, I think there may have been some questions as well about what each line represents. Is each row happening at the same time, and what is the unit of time (clock, instruction, step, etc.)? Or is there some wiggle room between processors as @tigerpanda suggests?

I believe ach step is supposed to represent one time step. From the previous slide, it says that we can assume that "when one transaction causes another transaction to abort and re-execute, assume that the transaction "commit" of one transaction can overlap with the "begin" of the re-executing transaction." This describes what is happening in the row.

I think these assumptions are meant to simplify the table, so we can focus on thinking about which execution steps need to happen for P1, P2, and P3, and less about the exact wall-clock time.

Can compiler do out of order executions within an atomic section of the code because atomicity just ensures non interference by other threads but may not prevent compiler optimizations? In that case, the instructions may not execute in this program order but maybe dynamically determined at run time by the compiler?

Agreed that each step seems to represent a time step - we look at individual rows, and when we see a particular transaction committing, we can look at the other ongoing transactions to determine read/write conflicts. @shivalgo, this sounds reasonable - most reorderings of operations that deal with different memory locations don't seem problematic because the transaction is isolated and in a sense "invisible" to other threads dealing with the same memory locations until the transaction commits. So if there's a lot of relaxation with ordering requirements in atomic regions, does this mean atomic regions can be implemented especially quickly?

If these instructions happened at arbitrary times (e.g. we relaxed the one instruction per timestep constraint), would it ever be possible that we get different results for these "atomic" transactions based on the order of execution? I'd imagine it shouldn't be able to, just checking my understanding.

We compare the write set of the committing transaction to the read and write sets of the transactions that are in flight. Here transaction T2 is committing. The only element in the write set of T2 is E. Therefore, the only conflict is with T4 that read E.

At this step, the only commit we see is in P2, where T2 is commiting. We don't know anything about whether T1 or T4 are commiting yet. So we have to check that the write set of T2 is consistent with the read/write sets of T1 and T4, and we find a conflict with T4 reading E, since P2 wrote E. Is it possible for various steps within a process to run at the same time (reads/writes concurrently?)

In pessimistic transactions, is T4 aborted much earlier?

I don't think T4 would've been aborted earlier, because neither a pessimistic read nor a pessimistic write policy would have intersecting operations (from the perspective of T4)