Abstract: A system and method is provided for measuring lock usage in a non-intrusive manner. Measurements are performed only when a lock is contended. When a lock is requested and the lock is available (i.e., is not contended), the only data gathered is a counter that is incremented to keep track of the number of times the particular lock was requested. When a lock is contended, an operating system trace hook is requested. The trace hook records data such as the timestamp that the requester requested the lock, the request count, a stack traceback to identify the function corresponding to the requester, and the address of the lock that was requested. Post-operative processing analyzes the recorded trace hook data to identify contended locks and processes that may not be efficiently using locks.

Abstract: A method for substantially reducing the latency of the database (DB) logging process by removing the agent notification requirement from the DB logger and allowing the DB logger to proceed to the next commit process without the latency of providing each waiting agent a notification that the agent continue their respective processes. When an agent commits a change to persistent storage of the database, the request is received by the logger, which performs the update to the persistent storage. A list of agents waiting on the completion of the commit process is compiled by the logger. The list of agents is provided to and provided to the next committing agent. The next committing agent then notifies the waiting agents that they are able to proceed with their respective processing. The logger may immediately perform the next update to persistent memory without utilizing a substantial amount of time notifying the waiting agents.

Abstract: A system and method is provided for measuring lock usage in a non-intrusive manner. Measurements are performed only when a lock is contended. When a lock is requested and the lock is available (i.e., is not contended), the only data gathered is a counter that is incremented to keep track of the number of times the particular lock was requested. When a lock is contended, an operating system trace hook is requested. The trace hook records data such as the timestamp that the requestor requested the lock, the request count, a stack traceback to identify the function corresponding to the requestor, and the address of the lock that was requested. Post-operative processing analyzes the recorded trace hook data to identify contended locks and processes that may not be efficiently using locks.

Abstract: An improved system and method for improving complex storage locks that manage access to a shared resource. A FIFO queue is maintained for processes waiting to read or write to the shared resource. When the shared resource is available, the first item is read from the queue. If the first item is a write requestor, the requestor is woken up in order to request the lock. If the first item on the queue is a read requestor, then that read requestor is woken up along with any other read requestors read from the queue until a write requestor is encountered or the end of the queue is reached. When the write wanted flag is set, new read requestors are denied access to the read lock, however any read requestors that were woken up in order to use the read lock are granted a read lock.

Abstract: An improved system and method for improving complex storage locks that manage access to a shared resource. A FIFO queue is maintained for processes waiting to read or write to the shared resource. When the shared resource is available, the first item is read from the queue. If the first item is a write requester, the requestor is woken up in order to request the lock. If the first item on the queue is a read requester, then that read requester is woken up along with any other read requesters read from the queue until a write requestor is encountered or the end of the queue is reached. When the write wanted flag is set, new read requesters are denied access to the read lock, however any read requesters that were woken up in order to use the read lock are granted a read lock.

Abstract: An exception handler for a computer system, particularly for performance monitoring facilities, employs implementation-dependent steps executed from a kernel extension which is more application level than kernel level. The implementation-independent kernel is involved only at very minimum level for a prologue to the exception handling routine. First a kernel extension registers an exception with the processor by storing the address of a pointer to a first-level interrupt handler; this address is stored in a location in kernel data storage, in non-paged memory. When an exception condition is reached, state is saved and the address location is checked to see if an exception has been registered. If so, the address is used to go to the first-level interrupt handler, which is at the kernel extension level. The first-level interrupt handler may access a second-level interrupt handler.

Abstract: A method and apparatus for maintaining a list for threads which are awaiting their occurrence of event. First a thread is detected that desires to perform some type of action based upon the occurrence of an event. Thereafter, the value of an event list anchor is set to indicate that it is currently unavailable. Thereafter, the value of the event list anchor set equal to the identification of the second thread.

Abstract: A method and system for altering data contained in a structure without requiring a lock to the structure itself. The method and apparatus retrieve a pointer to the structure from a location responsible for maintaining a pointer to the structure. The structure has a reference count for indicating processes that are currently using the data residing within the structure itself. The reference count is then atomically incremented and a new structure is obtained. The data contained in the structure, to be altered, is then copied to the new structure. The new structure also has a reference count for indicating processes that are currently using the data residing in the new structure. The reference count of the new structure is then set to indicate that a single process is accessing the new structure. Thereafter, the pointer in the responsible location for the structure, to be altered, is atomically replaced with a pointer to the new structure.

Abstract: An exception handler for a computer system, particularly for performance monitoring facilities, employs implementation-dependent steps executed from a kernel extension which is more application-level than kernel level. The implementation-independent kernel is involved only at very minimum level for a prologue to the exception handling routine. First, a kernel extension registers an exception with the processor by storing the address of a pointer to a first-level interrupt handler; this address is stored in a location in kernel data storage, in non-paged memory. When an exception condition is reached, state is saved and the address location is checked to see if an exception has been registered. If so, the address is used to go to the first-level interrupt handler, which is at the kernel extension level. The first-level interrupt handler may access a second-level interrupt handler.

Abstract: A method and apparatus for monitoring the execution of a procedure having multiple exit points without modifying the software via breakpoints. The starting address of the procedure is loaded into an Instruction Address Break Register (IABR). Upon execution of the starting address the IABR raises an exception. The processing of the exception is used to implement a counting routine and for loading the IABR with the address of the calling party via the Link Register. Upon execution of the address of the calling party, the IABR once again raises an exception. The processing of the second exception is used for stopping the counter and performing any related analysis.

Abstract: An exception handler for a computer system, particularly for performance monitoring facilities, employs implementation-dependent steps executed from a kernel extension which is more application-level than kernel level. The implementation-independent kernel is involved only at very minimum level for a prologue to the exception handling routine. First a kernel extension registers an exception with the processor by storing the address of a pointer to a first-level interrupt handler; this address is stored in a location in kernel data storage, in non-paged memory. When an exception condition is reached, state is saved and the address location is checked to see if an exception has been registered. If so, the address is used to go to the first-level interrupt handler, which is at the kernel extension level. The first-level interrupt handler may access a second-level interrupt handler.