In most of the cases, the main RIDE thread creates a worker thread that carries out some task with a container, e.g. the data dumping thread. The main thread then just spins in the Windows message loop, eventually doing nothing, waiting for the worker to complete. So in most of the cases, containers are accessed from within just one thread (main thread or a single worker thread).
However, if switched to the Track Map tab with its own worker thread, there now can be two workers that might want to access a single container simultaneously. At this moment, such uncoordinated access can lead to memory leaks (container is commanded from two threads to create the same cylinder), memory corruptions (container is commanded to dispose the same cylinder from two threads) and generally data inconsistencies (one thread commands floppy head over Cylinder 5, the other over Cylinder 13, and then both receive some random data, if any).
Synchronization assets should be used to prevent from above sketched problems.
In most of the cases, the main RIDE thread creates a worker thread that carries out some task with a container, e.g. the data dumping thread. The main thread then just spins in the Windows message loop, eventually doing nothing, waiting for the worker to complete. So in most of the cases, containers are accessed from within just one thread (main thread or a single worker thread).
However, if switched to the Track Map tab with its own worker thread, there now can be two workers that might want to access a single container simultaneously. At this moment, such uncoordinated access can lead to memory leaks (container is commanded from two threads to create the same cylinder), memory corruptions (container is commanded to dispose the same cylinder from two threads) and generally data inconsistencies (one thread commands floppy head over Cylinder 5, the other over Cylinder 13, and then both receive some random data, if any).
Synchronization assets should be used to prevent from above sketched problems.