Managing Concurrency

This section continues from the “The Global Data Store | Managing Concurrency” section. That section asserts that concurrency can be managed by gDS in conjunction with the rest of the test platform code.

The techniques involved in the test platform code are:

System locks — A system lock guarantees only one piece of code that uses the system lock executes at a time. A system lock is the “strictest” lock one can use. Typically, only one system lock is used in a test platform until there are performance issues with it being used too often. Because system locks are widely used within the test platform, they are used for as short a time as possible.

Atomic row add — Remember, the gDS “row add” code always adds the RowStatus column last to the table row. If that code is executing under a system lock, the row add becomes an atomic operation as long as any other “row add” operations use the same lock. Any code iterating through the table rows using the RowStatus column will either reference the new row or not. The code doing the iterating does not have to be under a system lock for this behavior to be true.

Row locks — If a row needs to be used for a while, a row lock is used. Here, the code looks at random RowStatus columns to find a row that is not being used or erased. The RowStatus column is updated to indicate the row is in use, and the requesting thread uses the row until it's no longer needed. At that time, the RowStatus column is set to “unused.” See the routine "allocateAnAnimal" in animalFarm_02 for an example that doesn't “hang” the system while looking for available animal rows.

Erasing rows — While a test is running, some rows of a table may need to be eliminated, but they may still be involved in the overall configuration of the test platform. One method is to mark the row as “Erased” until the end of a run and then process it so it can be deleted.

Parallel resources — Suppose you are testing a system that can support some number of “users.” The test platform can start with a table called gUser. It can spawn a thread for each desired user and have each thread create a row in the gUser table (under system lock). Then, each thread can use the columns in its row to work with the users in the system under test.