This is good slide for a "summarize in your own words" comment. I'd like to hear your take on the difference in semantics between atomic construct and lock and unlock operations on a mutex.
iZac
atomic construct is declarative, programmer just says that the piece of code needs to be done atomically and doesn't care how the system implements it.
On the other hand, lock and unlock construct is one way for the programmer to implement the atomicity. It may not be the best one!
kayvonf
@iZac. Great answer!
HLAHat
To add to this, "lock" and "unlock" don't say anything about code being atomic by themselves. They are just tools that the programmer can use to implement atomicity, but they could be used for other purposes too. "atomic" explicitly states that the code is atomic in every case it is used.
rokislt10
As a real-world example, locking is like having a special room that you shove workers into, and workers can only do work while in that room. Using atomic operations is like telling the workers what specific peices of work they can and cannot do while other workers are doing work.
landuo
I think this is an example of abstraction vs. implementation.
atomic is declarative which means that it states what kind of behavior the programmer wants for certain piece of code but without concerning actual implementation.
lock/unlock is imperative which means the programmer explicitly tries to implement atomic using locks.
dumbo_
atomic is declarative, it defines what the programmer think should be done. locks are imperative, which describes how things should be done. I think it's also an example of abstraction vs implementation, where atomic is a concept but lock/unlock is one kind of implementation of this concept. Moreover, it might not be the most suitable implementation under certain cases and it can be used to implement other abstractions as well. Also for atomic, it's the programmer's duty to declare the atomic region, wrong declaration can still cause atomicity violations.
rhnil
atomic provides the abstraction that the code within the region is executed in isolation and serializable logically, but it does not preclude concurrent execution if there is no read/write or write/write conflicts. In contrast, if we choose lock()/unlock() as a specific implementation for atomic, all operations are essentially serialized, and it is difficult to clean up corrupted states and ensure atomicity in the case of failure.
This is good slide for a "summarize in your own words" comment. I'd like to hear your take on the difference in semantics between
atomicconstruct andlockandunlockoperations on a mutex.atomic construct is declarative, programmer just says that the piece of code needs to be done atomically and doesn't care how the system implements it.
On the other hand, lock and unlock construct is one way for the programmer to implement the atomicity. It may not be the best one!
@iZac. Great answer!
To add to this, "lock" and "unlock" don't say anything about code being atomic by themselves. They are just tools that the programmer can use to implement atomicity, but they could be used for other purposes too. "atomic" explicitly states that the code is atomic in every case it is used.
As a real-world example, locking is like having a special room that you shove workers into, and workers can only do work while in that room. Using atomic operations is like telling the workers what specific peices of work they can and cannot do while other workers are doing work.
I think this is an example of abstraction vs. implementation. atomic is declarative which means that it states what kind of behavior the programmer wants for certain piece of code but without concerning actual implementation. lock/unlock is imperative which means the programmer explicitly tries to implement atomic using locks.
atomic is declarative, it defines what the programmer think should be done. locks are imperative, which describes how things should be done. I think it's also an example of abstraction vs implementation, where atomic is a concept but lock/unlock is one kind of implementation of this concept. Moreover, it might not be the most suitable implementation under certain cases and it can be used to implement other abstractions as well. Also for atomic, it's the programmer's duty to declare the atomic region, wrong declaration can still cause atomicity violations.
atomicprovides the abstraction that the code within the region is executed in isolation and serializable logically, but it does not preclude concurrent execution if there is no read/write or write/write conflicts. In contrast, if we chooselock()/unlock()as a specific implementation foratomic, all operations are essentially serialized, and it is difficult to clean up corrupted states and ensure atomicity in the case of failure.