Labelling the block of code as atomic is a declarative way of achieving transactional behavior, while protecting access to it with a lock is an imperative way of achieving it. The declarative way in this case does not mention the explicit way in which this transactional behavior should be implemented: it trusts that the system has a mechanism to do the same in the most optimal way in any given context. For instance, it could be with locks during periods of high contention and using optimistic concurrency during periods of low contention. This offloads the burden of additional development effort to ensure optimal performance from the programmer to the system.
paramecinm
The transactional memory requires atomicity, isolation and serializability. Does the declarative atomic block means transactional memory or only atomicity?
sreevisp
@paramecinm: The atomic construct here is just a semantic idea used in the slides to illustrate this example. In theory, I believe it represents the processor executing the enclosed block of code as if it were one individual instruction. In that sense, I suppose it would be fully transactional but it's possible to imagine implementations where that's not the case.
jedi
The atomic construct in the example above is practical only if the underlying system can figure out that the implementation should grab per-account locks instead of global locks.
muchanon
This difference is similar to ISPC versus SIMD vector instructions. ISPC declares pieces of independent work. Vector instructions are an implementation choice for parallelizing work. When using ISPC, we declare the independent work, and let it decide how to schedule/translate it to machine instructions.
themj
How does the underlying system know what the optimal way of guaranteeing atomicity is?
Labelling the block of code as atomic is a declarative way of achieving transactional behavior, while protecting access to it with a lock is an imperative way of achieving it. The declarative way in this case does not mention the explicit way in which this transactional behavior should be implemented: it trusts that the system has a mechanism to do the same in the most optimal way in any given context. For instance, it could be with locks during periods of high contention and using optimistic concurrency during periods of low contention. This offloads the burden of additional development effort to ensure optimal performance from the programmer to the system.
The transactional memory requires atomicity, isolation and serializability. Does the declarative atomic block means transactional memory or only atomicity?
@paramecinm: The atomic construct here is just a semantic idea used in the slides to illustrate this example. In theory, I believe it represents the processor executing the enclosed block of code as if it were one individual instruction. In that sense, I suppose it would be fully transactional but it's possible to imagine implementations where that's not the case.
The atomic construct in the example above is practical only if the underlying system can figure out that the implementation should grab per-account locks instead of global locks.
This difference is similar to ISPC versus SIMD vector instructions. ISPC declares pieces of independent work. Vector instructions are an implementation choice for parallelizing work. When using ISPC, we declare the independent work, and let it decide how to schedule/translate it to machine instructions.
How does the underlying system know what the optimal way of guaranteeing atomicity is?