Browse Prior Art Database

Gate Semaphore for Increased Performance Disclosure Number: IPCOM000016066D
Original Publication Date: 2002-Jul-28
Included in the Prior Art Database: 2003-Jun-21

Publishing Venue



In situations where multiple dependent read-often/write-seldom fields are referenced, it would be desirable to access said fields without the overhead of acquiring a serialization mechanism every time the fields must be read. It is not possible to simply forego the serialization mechanism for reads since these are dependent fields which must remain consistent with one another. A read while the fields are in the midst of being written is invalid. The standard solution is to acquire an exclusive serialization mechanism for writes and a shared serialization mechanism for reads. For frequently read fields, this shared serialization can represent significant overhead. A mechanism is needed which will allow reduced overhead for reads while still guaranteeing consistency among the dependent fields. Disclosed is a programming device that will enable the user to verify that data is in a consistent state while making decisions based on the data while avoiding the use of a costly (from a performance perspective) serialization mechanism. The invention implements what we will call a flux counter. The flux counter is initialized to zero. Whenever a state change occurs that would affect the flags and fields we are interested in, the process changing state increments the flux count acquires a serialization mechanism (gate, seize, etc.). Once the state change has completed, the serialization mechanism is released and the flux count is again incremented. In this way, a state change in progress is always indicated by a flux count containing an odd value (1, 3, 5, 7, etc). When the state, flags or fields must be used as part of a decision making process, first the flux count is copied, then the state and related flags and fields are copied. The true flux count is then checked, if it contains an odd value, the state is in flux and we must acquire the serialization mechanism in order to have a consistent state from which to make our decision. If the true flux count contains an even value but is greater than the copied flux count, then we know a state change occurred. If state changes occur frequently, we may want to acquire the serialization mechanism to get a consistent state or, if state changes do not occur frequently, we can repeat the process of copying the flux count plus the state and related fields until the copied flux count and the true flux count are even and identical (since state changes are infrequent, we would normally only have to re-copy once). Once we have cached a consistent image of the necessary fields, we can use those fields to make our decision. Fields do not have to reside within one specific object for the flux count to be effective. Pseudocode example: This example uses only one state (objState) and one related field (objNeedsProc), but any number of related fields and flags can be copied and used in decision making processes with this algorithm.