Understanding Contention

Once a lock table entry has became incompatible, XES will begin to incur significant overhead when processing requests for ANY resource that maps to that entry. This overhead will continue to be incurred until the composite state of the lock table entry returns to the shared or free state. A lock table entry can become incompatible for one of the following reasons:

Resource Contention
As previously described, resource contention occurs when the corresponding resource request queue becomes “in contention”, that is, an entry is added that is incompatible with the existing entries. For example, User 1 requests to own resource ABC with hash value 3 in the exclusive state but the resource is already owned by User 2. In this case, XES will assign management of the resource request queue to a connected user.

Because all the entries on a particular resource request queue map to the same lock table entry, it follows that if a particular resource request queue is “in contention”, then the corresponding lock entry also is “in contention”. Thus, resource contention incurs the overhead associated with processing an incompatible lock table entry PLUS the cost of any actions performed by the application's contention exit.
False Contention
False contention is the term that describes other conditions that could cause a lock entry to reach the incompatible state. One such condition that could result in false contention is when two different resource names have the same hash value thus causing a collision at the lock table entry level. This is referred to as “hash class” contention.

In the following example, User 1 owns a resource with a name of ABC and a hash value of 27 in the exclusive state and User 2 owns a resource with a name of DEF and a hash value of 27 in a shared state. Note that the requests represent different resources, each belonging to a separate compatible resource request queue. While there is no contention at the resource level (and thus no need to involve the contention exit), the corresponding lock table entry is incompatible causing the application to incur the previously described processing overhead.

Hash Class Contention

        User 1 - Owner                   User 2 - Requestor

      IXLLOCK REQUEST=OBTAIN           IXLLOCK REQUEST=OBTAIN

         RNAME=ABC                        RNAME=DEF
         HASHVAL=27                       HASHVAL=27
         STATE=EXCL                       STATE=SHR

Another condition which could result in overhead due to false contention is when two resources with distinct hash values collide at the lock table entry due to the wrap-around condition described previously.

In the following example, assume a lock table with 8 entries. User 1 owns a resource with a name of ABC and a hash value of 1. User 2 requests a resource represented by resource name DEF and a hash value of 9. Because the lock table contains only 8 lock table entries, hash value 9 will “wrap-around” and map to lock table entry 1. Once again, while the following example does not result in resource contention and the need to involve the contention exit, the application will incur the overhead required to process requests for resources mapping to a lock table entry that is in an incompatible state.

Wrap-Around Condition

        User 1 - Owner                   User 2 - Requestor

      IXLLOCK REQUEST=OBTAIN           IXLLOCK REQUEST=OBTAIN

         RNAME=ABC                        RNAME=DEF
         HASHVAL=1                        HASHVAL=9
         STATE=EXCL                       STATE=SHR

In summary, the overhead incurred by XES to process requests that experience contention (whether it be false contention or resource contention) is significant. The performance of your application can be severely impacted as the number of requests that experience contention increases. For this reason, an application should design a protocol which attempts to reduce the likelihood of this occurrence.