Issues in using shared rows without ATOMIC blocks

Updating two different elements of a shared row variable, by using separate statements on one thread while another thread reads from the same shared row, can lead to the reading thread seeing intermediate results with only part of the updated data being visible.

Using separate statements can often appear to work perfectly, as the two threads might not collide. For example, the following illustration shows the reader thread reading a consistent set of values:

However, if the reader thread reads the shared row in the middle of the update by the writer thread, it will see inconsistent data:

This problem occurs more often as the number of threads increases. Although it might seem possible to solve this by writing atomically into the shared row (by building up a structure in a local variable, and then assigning it into the shared variable), this will not work if the reading thread uses multiple statements to read the data:

Consistent data will be seen at all points on the threads only if both threads atomically read and write data:

This approach relies on the ESQL language using read-write locks to ensure that the data can be read and written atomically with no danger of interleaving. Despite the low-level locking keeping the server from crashing and allowing some techniques to keep data coherent across threads, the ATOMIC keyword is usually required to achieve useful results for most applications.