In-Memory OLTP Internals - Pro SQL Server Internals - page 645

Figure 32-7. Delta records and range index leaf page
SQL Server uses an InterlockedCompareExchange mechanism to guarantee that multiple sessions cannot update
the same pointer chain and thus overwrite each other's changes, thereby losing references to each other's objects.
InterlockedCompareExchange functions change the value of the pointer, checking that the existing ( pre-update ) value
matches the expected ( old) value provided as another parameter. Only when the check succeeds, the pointer value is
updated.
Let's look at an example, which assumes that we have two sessions into which we want to insert new delta
records for the same index page simultaneously. As a first step, shown in Figure 32-8 , sessions create delta records and
set their pointers to a page based on the address from the mapping table.
Figure 32-8. Data modifications and concurrency: Step 1
In the next step, both sessions call the InterlockedCompareExchange function trying to update the mapping table
by changing the reference from a page to the newly created delta records. InterlockedCompareExchange serializes
the update of the mapping table element and changes it only if its current pre-update value matches the old pointer
(address of the page) provided as the parameter. The first InterlockedCompareExchange call would succeed. The
second call, however, would fail because the mapping table element would reference the delta record from another
session rather than the page. Therefore, the second session will need to redo or rollback the action based on the
requirements and a use-case.
Figure 32-9 illustrates such a scenario. As you can see, with the exception of a very short serialization during the
InterlockedCompareExchange call, there is no locking or latching of the data during the modifications.