This code can be made thread safe by wrapping all but the first two lines with atomic{}

Would it still be correct, just less performant to wrap the entire function in atomic()? Otherwise it seems that we still need to think a bit about "fine-graining" the sections except just without the implementation details of the locking and unlocking

@tspint My understanding is that yes, it would still be functionally correct but potentially a lot less performant. We usually consider malloc to be an expensive operation, so putting it int he atomic region could potentially result in a rather drastic decrease in performance (same idea if we were doing this with locks and had to hold the queue lock while doing the malloc).

@nickbowman or others, would the system not be able to figure out that there are no conflicts in the first two lines if we wrap the whole function in atomic{}? At what point do we have to be explicit about atomicity? It seems that it's at the data structure level.

@pmp I think that it is not the system's job in this case to look for potential parallelism. When specifying that a region is atomic, the system will ensure atomicity but will not try to find improvements over our decision.

I think agree with @marwan. Transactional memory isn't really a compiler and it might only exist in hardware. Also as we see later, transactional memory implementations seem to do their "collision detection" dynamically. So, if we were to wrap the entire routine in atomic{} then we might be forced to abort and deallocate memory before retrying and allocating memory again.

As a follow-up to this: what are the benefits for a HW-bound TM implementation over SW? It would seem like HW implementations could integrate better into instruction execution and memory operations especially in the case of exceptions.

A good question raised in lecture chat: Why do we need to include the third line of accessing the left sentinel in the atomic section? I feel like we don't need to.