Broker-allocated shared memory can be updated by multiple clients and servers. To prevent shared memory from being updated by two users simultaneously, OpenEdge uses spin locks. Each portion of memory contains one or more latches to ensure that two updates cannot happen simultaneously. When a user modifies a portion of shared memory, the user gets a latch for that resource and makes the change. Other users who need the resource respect the latch. By default, when a latch is established on a resource and a user needs that resource, that user tries for the resource once and then stops trying. On a single CPU system, you should only try the operation once because the resource cannot be freed until the resource that has the latch can use the CPU. This is the reason for this default action.

On a multiple CPU system, the default action is not very efficient because a significant amount of resource time is used to activate a different process on the CPU. This effort is wasted if the resource is not available. Typically, a resource is only busy and latched for a very short time, so it is more efficient to ask to obtain the resource many times rather than just once, and then go to the end of the CPU queue and then proceed through the queue back to the top before asking a second time to get the resource. The –spin parameter determines the number of times to ask before proceeding to the end of the CPU queue.

Generally, a setting between 2,000 and 10,000 works for the majority of systems, but this varies greatly. Monitor the number of naps-per-second per resource. If the naps-per-second value for any given resource exceeds 30, you might try increasing the value of –spin. This can be done while the system is running through the PROMON R&D option.