Low-level shared variable locking without ATOMIC blocks

The integration server provides locking around shared variable access to prevent crashes and deadlocks, regardless of whether ATOMIC blocks are used.

In the following scenario, the code is attempting to read from and write to the same shared row variable, and the ESQL language takes a read lock to read the initial data followed by a write lock to update the result. Due to the order of operations and the lack of "upgrade read lock to write lock" capability, two separate locking operations are required:

Although it appears to be possible to loop around a set of elements within a shared variable while updating the same shared variable, this would cause a deadlock due to the lack of "upgrade read lock to write lock" capability, and as a result the ESQL language will throw a BIP2503 exception when it detects the write attempt:

Attempting to write to different shared variables will also result in the same exception, as allowing one thread to attempt to take a write lock on one variable while holding a read lock on another could result in a deadlock with a different thread attempting to take the same locks in the opposite order.

These examples are all in a single ESQL node, as propagating from a node while holding a lock is prohibited. The reason for this is that the information on what locks have been taken on a particular thread is stored per-node, so downstream nodes would not know which locks are held by upstream nodes. As no checking could be performed, deadlocks would be possible, and this leads to flows that cannot be shut down.