Adding in priority commands to the bit-test-and-clear approach really doesn t stop the abuse of the SRAM unit. The example code of the previous section is not going be a good neighbor to other code that uses SRAM because the SRAM order command queue is continuously backlogged. One solution is to use a combination of techniques learned from Chapter 6 along with the bit-test-and-clear operations. Instead of having all of the threads in a microengine performing bit-test-and-clear operations, use a shared variable to ensure that only one thread in each microengine is actively performing the bit-test-and-clear operation. However, such a solution is really no different than running the current code on only one thread in each microengine. So with our basic design, the only solution is to find a different synchronization mechanism that does not require all of the threads to read memory in a tight spin loop. SRAM CAM locks provide just such a mechanism.

The SRAM unit has commands to lock and unlock any SRAM memory address. Once a thread has obtained a lock on an address, any other thread attempting to lock that same address is blocked from execution until the address is unlocked. How does the SRAM unit block the execution of a thread? By simply withholding the signal that the lock command has completed! A thread that issues a lock command on an already locked address believes that it is just experiencing the longest SRAM latency in history.

Up to eight different...