US6301676B1 - Robust and recoverable interprocess locks - Google Patents

Robust and recoverable interprocess locks Download PDF

Info

Publication number
US6301676B1
US6301676B1 US09/235,881 US23588199A US6301676B1 US 6301676 B1 US6301676 B1 US 6301676B1 US 23588199 A US23588199 A US 23588199A US 6301676 B1 US6301676 B1 US 6301676B1
Authority
US
United States
Prior art keywords
lock
acquire
attempt
program state
holding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US09/235,881
Inventor
Aswini S. Kumar
Daniel A. Stein
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle America Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Priority to US09/235,881 priority Critical patent/US6301676B1/en
Assigned to SUN MICROSYSTEMS, INC. reassignment SUN MICROSYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: STEIN, DANIEL A., KUMAR, ASWINI S.
Priority to EP00200223A priority patent/EP1028378A3/en
Priority to JP2000013313A priority patent/JP4327972B2/en
Application granted granted Critical
Publication of US6301676B1 publication Critical patent/US6301676B1/en
Assigned to Oracle America, Inc. reassignment Oracle America, Inc. MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: Oracle America, Inc., ORACLE USA, INC., SUN MICROSYSTEMS, INC.
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526Mutual exclusion algorithms

Definitions

  • the present invention relates to inter-process synchronization mechanisms in computer systems. More specifically, the present invention relates to a method and apparatus for implementing inter-process locks that provides for robust recovery in the event a process fails while holding a lock.
  • mutex locks mutual exclusion locks
  • a process typically attempts to “acquire” a lock before executing a critical section of code or accessing specific items of shared data. If no other process presently holds the lock, the process acquires the lock by setting the lock to a locked state. After acquiring the lock, the process is free to execute the critical section of code or manipulate the items of shared data without interference from other processes. While the process holds the lock, other processes attempting to acquire the lock will “block” waiting for the lock, and will not be able to proceed until the lock is released. After the process completes the task, it releases the lock, thereby allowing other processes to acquire the lock.
  • Mutual exclusion locks create complications for computer systems that operate robustly. Such “robust” computer systems are designed to continue processing even if some of the processes or processors involved in a computational task fail during program execution. If a process fails while holding a mutual exclusion lock, other processes attempting to acquire the lock will “hang,” waiting for the failed process to release the lock. The computational task will consequently come to a halt.
  • What is needed is a method or an apparatus that provides robust recoverable locks that do not let other processes hang if a process holding a lock fails, and which allows the other processes to restore the state protected by the lock to a consistent state.
  • One embodiment of the present invention provides a system that supports recovery in the event a previous process holding a lock used for mutual exclusion purposes loses ownership of the lock. This loss of ownership may occur due to the previous process dying or the lock becoming unmapped.
  • a process first attempts to acquire the lock. If the attempt to acquire the lock returns with an error indicating that the previous process holding the lock lost ownership of the lock, the process attempts to make program state protected by the lock consistent. If the attempt to make the program state consistent is successful, the system reinitializes and unlocks the lock. Otherwise, the system marks the lock as unrecoverable so that subsequent processes attempting to acquire the lock are notified that the lock is not recoverable.
  • One aspect of the present invention includes receiving a notification in an operating system that a process died, and determining if the process died while holding a lock. If the process died while holding the lock, the system marks the lock to indicate to subsequent acquirers of the lock that a previous holder of the lock died, and unlocks the lock so that other processes may acquire the lock.
  • the process if the attempt to acquire the lock returns with an error indicating the lock is not recoverable, the process performs operations to work around the program state that is inconsistent, and reinitializes the lock.
  • FIG. 1 illustrates a computer system that is able to execute multiple processes in accordance with an embodiment of the present invention.
  • FIG. 2 illustrates part of the internal structure of an operating system in accordance with an embodiment of the present invention.
  • FIG. 3 illustrates some of the data structures involved in implementing robust locks in accordance with an embodiment of the present invention.
  • FIG. 4 is a flow chart illustrating how an operating system handles a process that dies while holding a lock in accordance with an embodiment of the present invention.
  • FIG. 5 is a flow chart illustrating how a robust lock is used in accordance with an embodiment of the present invention.
  • a computer readable storage medium which may be any device or medium that can store code and/or data for use by a computer system.
  • the carrier wave may originate from a communications network, such as the Internet.
  • FIG. 1 illustrates a computer system that is able to execute multiple processes in accordance with an embodiment of the present invention.
  • the system includes central processing unit (CPU) 102 , which is coupled to memory 104 .
  • CPU 102 may include any type of computing device that is capable of processing code and/or data. This includes, but is not limited to, a mainframe processor, a multi-processor, a microprocessor, a device controller, and a computational unit within an appliance.
  • Memory 104 includes any type of random access memory that can be used to store code and/or data for execution by CPU 102 .
  • CPU 102 may be coupled to memory 104 in a number of ways, including through a dedicated processor-to-memory bus, through a system bus or through an intervening core logic unit.
  • CPU 102 is additionally coupled to a number of other peripherals through bus 106 .
  • peripherals include disk 108 , network interface controller (NIC) 110 , display 112 and keyboard 114 .
  • Disk 108 refers to any type of secondary storage device, including a magnetic or optical disk drive or a tape drive.
  • NIC 110 includes circuitry for coupling the computer system to a computer network 113 .
  • Network 113 may be any type of network or collection of networks that can be used to couple together computer systems, such as a local area network and/or a wide area network.
  • Display 112 may be any output device for the computer system, including a computer monitor for graphical images or an audio output device, for audio data
  • Keyboard 114 may include any type of device for receiving input into a computer system. This includes, but is not limited to, a computer keyboard and a computer mouse.
  • FIG. 1 Note that although a particular implementation of a computer system is illustrated in FIG. 1, the present invention applies generally to all computer systems that can run multiple processes, including computer systems with multiple processors.
  • FIG. 1 additionally illustrates operating system 120 , which facilitates execution of a collection of processes, including processes 122 , 124 and 126 .
  • Processes 122 , 124 and 126 may be any type of processes that are commonly executed by a computer system, including lightweight processes and heavyweight processes, as well as system processes and user processes.
  • Shared memory 128 may be a region of share semiconductor memory 104 , or alternatively a shared file.
  • Shared memory 128 includes mutex lock 130 , which is mutual exclusion lock used by processes 122 , 124 and 126 for providing exclusive access to a critical section of code or to items of shared data in memory 104 .
  • FIG. 2 illustrates part of the internal structure of operating system 120 in accordance with an embodiment of the present invention.
  • Operating system 120 includes a number of layers and functional modules, including user threads layer 208 , kernel threads layer 206 , scheduler 204 and device driver 202 .
  • Device driver 202 includes device drivers for operating devices attached to the computer system.
  • device driver 202 may include a device driver for accessing disk 108 and a device driver for accessing NIC 110 .
  • Scheduler 204 includes resources for scheduling threads and or processes for execution on one or more central processing units. Scheduler 204 manipulates both kernel threads 206 and user threads 208 . Kernel threads 206 include kernel-level threads that operate entirely on operating system functions inside of operating system 120 , as well as lightweight process threads 207 that are associated with user threads 208 . User threads 208 are used to execute user programs. In the embodiment illustrated in FIG. 2, multiple user threads 208 can be mapped onto a single lightweight process thread 207 .
  • FIG. 3 illustrates some of the data structures involved in implementing robust locks in accordance with an embodiment of the present invention.
  • This embodiment illustrates process state 302 , which contains state associated with a process that has access to mutex lock 308 , such as process 122 from FIG. 1 .
  • Process state 302 includes state associated with process 122 . This state is stored in a data structure (or data object) within operating system 120 . For example, process state 302 includes a list of open files 304 for the process.
  • lock registry 306 which includes a list of locks that may be in use by process 122 . For example, in FIG. 3, lock registry 306 contains a pointer to mutex lock 308 .
  • Lock registry 306 allows operating system 120 to determine if process 122 died while holding a lock. After a mutex lock 308 is initialized, it is registered in the lock registry 306 of any processes that desires to have access to mutex lock 308 . For example, mutex lock 308 may be registered in lock registry 306 for process 122 . This allows the operating system to determine and identify any locks that process 122 holds when and if process 122 dies. Note that lock registry 306 may alternatively reside outside of process state 302 in a separate lock registry table that is indexed by process identifier.
  • Mutex lock 308 contains state associated with a lock. This state includes lock flag 310 , consistency flag 312 , recoverability indicator 314 and lock type indicator 316 .
  • Lock flag 310 includes a byte or word of data indicating whether or not mutex lock 308 is locked. While mutex lock 308 is held by a process, lock flag 310 is set to a locked state so that other processes cannot acquire mutex lock 308 .
  • Consistency flag 312 indicates whether or not the program state protected by mutex lock 308 is consistent.
  • Recoverability indicator 314 indicates whether or not the process state protected by mutex lock 308 is recoverable after a process holding mutex lock 308 dies.
  • lock type indicator 316 indicates what type of lock mutex lock 308 is. For example, lock type indicator 316 may indicate whether mutex lock 308 is a robust lock or a non-robust lock.
  • FIG. 4 is a flow chart illustrating how an operating system handles a process that dies while holding a mutex lock 308 in accordance with an embodiment of the present invention.
  • operating system 120 first receives a notification that a process 122 died (step 402 ).
  • Operating system 120 examines a lock registry 306 within process state 302 to determine if process 122 died while holding mutex lock 308 (step 404 ). If so, operating system 120 marks the mutex lock 308 to indicate that a previous process died while holding mutex lock 308 , and then unlocks mutex lock 308 by unmarking lock flag 310 in FIG. 3 . This allows a subsequent process to grab mutex lock 308 and to determine that process 122 died while holding mutex lock 308 .
  • operating system 120 may indicate that a previous process died while holding mutex lock 308 by setting consistency flag 312 in FIG. 3 to an inconsistent state.
  • consistency flag 312 may be set by a process that has acquired mutex lock 308 prior modifying the state protected by mutex lock 308 . After this process has finished modifying the state protected by mutex lock 308 , it unsets consistency flag 312 .
  • FIG. 5 is a flow chart illustrating how a robust lock is used in accordance with an embodiment of the present invention.
  • a process such as process 122 from FIG. 1, makes a function call in an attempt to acquire a lock, such as mutex lock 308 from FIG. 3 (step 502 ).
  • the function call examines lock flag 310 to determine if another process presently holds mutex lock 308 . If another process currently holds mutex lock 308 , process 122 blocks on mutex lock 308 . When the other process ultimately releases mutex lock 308 , process 122 acquires mutex lock 308 by marking lock flag 310 and the function call returns.
  • the system performs the required work on the program state protected by the mutex lock 308 (step 514 ). After the required work is performed, the system releases mutex lock 308 by unmarking lock flag 310 so that another process can acquire mutex lock 308 .
  • process 122 attempts to make the program state protected by mutex lock 308 consistent (step 504 ). If process 122 is able the make the program state consistent, it re-initializes mutex lock 308 and then unlocks mutex lock 308 (step 506 ). If process 122 is not successful in making the program state consistent, it marks mutex lock 308 as unrecoverable (by setting recoverability indicator 314 in FIG.
  • Process 122 will additionally unmark lock flag 310 to unlock mutex lock 308 . This allows other processes to acquire mutex lock 308 . Process 122 may also wake up processes that are waiting on mutex lock 308 .
  • process 122 knows that a previous process has already attempted to make the program state protected by mutex lock 308 consistent.
  • Process 122 attempts to work around the inconsistent program state by, for example, repeating program operations that were required to produce the program state to begin with, or alternatively by restarting the program from the beginning (step 510 ).
  • process 122 destroys mutex lock 308 (step 512 ) and reinitializes mutex lock 308 so that another process can acquire mutex lock 308 (step 512 ).
  • Tables 1 A and 1 B present an example in the C programming language of how one embodiment of robust locks is used.
  • the first portion of the main program (in Table 1 A) initializes the mutex lock.
  • the second portion of the main program (in Table 1 B) includes a loop that cycles through a “switch” statement. This switch statement handles the three cases of “owner dead,” “not recoverable” and “no error,” which correspond to the three-way branch in the flow chart of FIG. 5 .

Abstract

One embodiment of the present invention provides a system that supports recovery in the event a previous process holding a lock used for mutual exclusion purposes loses ownership of the lock. This loss of ownership may occur due to the previous process dying or the lock becoming unmapped. Under the present invention a process first attempts to acquire the lock. If the attempt to acquire the lock returns with an error indicating that the previous process holding the lock lost ownership of the lock, the process attempts to make program state protected by the lock consistent. If the attempt to make the program state consistent is successful, the system reinitializes and unlocks the lock. Otherwise, the system marks the lock as unrecoverable so that subsequent processes attempting to acquire the lock are notified that the lock is not recoverable. One aspect of the present invention includes receiving a notification in an operating system that a process died, and determining if the process died while holding a lock. If the process died while holding the lock, the system marks the lock to indicate to subsequent acquirers of the lock that a previous holder of the lock died, and unlocks the lock so that other processes may acquire the lock. According to one aspect of the present invention, if the attempt to acquire the lock returns with an error indicating the lock is not recoverable, the process performs operations to work around the program state that is inconsistent, and reinitializes the lock.

Description

COPYRIGHT NOTICE PURSUANT TO 37 C.F.R. §1.71(E)
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND
1. Field of the Invention
The present invention relates to inter-process synchronization mechanisms in computer systems. More specifically, the present invention relates to a method and apparatus for implementing inter-process locks that provides for robust recovery in the event a process fails while holding a lock.
2. Related Art
Computer systems often support multiple processes that can work together on a single computational task. One of the challenges in using multiple processes is to synchronize the processes so that they do not interfere with each other. This is typically accomplished through mutual exclusion locks (mutex locks), which are used to ensure that only one process at a time performs a particular task or has access to specific items of shared data.
A process typically attempts to “acquire” a lock before executing a critical section of code or accessing specific items of shared data. If no other process presently holds the lock, the process acquires the lock by setting the lock to a locked state. After acquiring the lock, the process is free to execute the critical section of code or manipulate the items of shared data without interference from other processes. While the process holds the lock, other processes attempting to acquire the lock will “block” waiting for the lock, and will not be able to proceed until the lock is released. After the process completes the task, it releases the lock, thereby allowing other processes to acquire the lock.
Mutual exclusion locks create complications for computer systems that operate robustly. Such “robust” computer systems are designed to continue processing even if some of the processes or processors involved in a computational task fail during program execution. If a process fails while holding a mutual exclusion lock, other processes attempting to acquire the lock will “hang,” waiting for the failed process to release the lock. The computational task will consequently come to a halt.
To remedy this problem, some computer systems simply release a lock if a process holding the lock fails. This allows other processes that are blocked on the lock to continue processing. However, the process that failed may have left the data protected by the lock in an inconsistent state. This may cause the remaining processes to produce an incorrect result or to fail at some time in the future.
Other systems notify the remaining processes that the state protected by the lock was left in an inconsistent state when the process died. This allows the remaining processes to take action to make the state consistent again. However, the remaining processes may not be successful in making the state consistent again. In this case, the remaining processes will ultimately produce an incorrect result or will fail at some time in the future.
What is needed is a method or an apparatus that provides robust recoverable locks that do not let other processes hang if a process holding a lock fails, and which allows the other processes to restore the state protected by the lock to a consistent state.
SUMMARY
One embodiment of the present invention provides a system that supports recovery in the event a previous process holding a lock used for mutual exclusion purposes loses ownership of the lock. This loss of ownership may occur due to the previous process dying or the lock becoming unmapped. Under the present invention a process first attempts to acquire the lock. If the attempt to acquire the lock returns with an error indicating that the previous process holding the lock lost ownership of the lock, the process attempts to make program state protected by the lock consistent. If the attempt to make the program state consistent is successful, the system reinitializes and unlocks the lock. Otherwise, the system marks the lock as unrecoverable so that subsequent processes attempting to acquire the lock are notified that the lock is not recoverable.
One aspect of the present invention includes receiving a notification in an operating system that a process died, and determining if the process died while holding a lock. If the process died while holding the lock, the system marks the lock to indicate to subsequent acquirers of the lock that a previous holder of the lock died, and unlocks the lock so that other processes may acquire the lock.
According to one aspect of the present invention, if the attempt to acquire the lock returns with an error indicating the lock is not recoverable, the process performs operations to work around the program state that is inconsistent, and reinitializes the lock.
BRIEF DESCRIPTION OF THE FIGURES
FIG. 1 illustrates a computer system that is able to execute multiple processes in accordance with an embodiment of the present invention.
FIG. 2 illustrates part of the internal structure of an operating system in accordance with an embodiment of the present invention.
FIG. 3 illustrates some of the data structures involved in implementing robust locks in accordance with an embodiment of the present invention.
FIG. 4 is a flow chart illustrating how an operating system handles a process that dies while holding a lock in accordance with an embodiment of the present invention.
FIG. 5 is a flow chart illustrating how a robust lock is used in accordance with an embodiment of the present invention.
DETAILED DESCRIPTION
The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital video discs), and computer instruction signals embodied in a carrier wave. For example, the carrier wave may originate from a communications network, such as the Internet.
Computer System
FIG. 1 illustrates a computer system that is able to execute multiple processes in accordance with an embodiment of the present invention. The system includes central processing unit (CPU) 102, which is coupled to memory 104. CPU 102 may include any type of computing device that is capable of processing code and/or data. This includes, but is not limited to, a mainframe processor, a multi-processor, a microprocessor, a device controller, and a computational unit within an appliance. Memory 104 includes any type of random access memory that can be used to store code and/or data for execution by CPU 102. Note that CPU 102 may be coupled to memory 104 in a number of ways, including through a dedicated processor-to-memory bus, through a system bus or through an intervening core logic unit.
CPU 102 is additionally coupled to a number of other peripherals through bus 106. These peripherals include disk 108, network interface controller (NIC) 110, display 112 and keyboard 114. Disk 108 refers to any type of secondary storage device, including a magnetic or optical disk drive or a tape drive. NIC 110 includes circuitry for coupling the computer system to a computer network 113. Network 113 may be any type of network or collection of networks that can be used to couple together computer systems, such as a local area network and/or a wide area network. Display 112 may be any output device for the computer system, including a computer monitor for graphical images or an audio output device, for audio data Keyboard 114 may include any type of device for receiving input into a computer system. This includes, but is not limited to, a computer keyboard and a computer mouse.
Note that although a particular implementation of a computer system is illustrated in FIG. 1, the present invention applies generally to all computer systems that can run multiple processes, including computer systems with multiple processors.
FIG. 1 additionally illustrates operating system 120, which facilitates execution of a collection of processes, including processes 122, 124 and 126. Processes 122, 124 and 126 may be any type of processes that are commonly executed by a computer system, including lightweight processes and heavyweight processes, as well as system processes and user processes.
Processes 122, 124 and 126 access shared memory 128, which may be a region of share semiconductor memory 104, or alternatively a shared file. Shared memory 128 includes mutex lock 130, which is mutual exclusion lock used by processes 122, 124 and 126 for providing exclusive access to a critical section of code or to items of shared data in memory 104.
Operating System
FIG. 2 illustrates part of the internal structure of operating system 120 in accordance with an embodiment of the present invention. Operating system 120 includes a number of layers and functional modules, including user threads layer 208, kernel threads layer 206, scheduler 204 and device driver 202. Device driver 202 includes device drivers for operating devices attached to the computer system. For example, device driver 202 may include a device driver for accessing disk 108 and a device driver for accessing NIC 110.
Scheduler 204 includes resources for scheduling threads and or processes for execution on one or more central processing units. Scheduler 204 manipulates both kernel threads 206 and user threads 208. Kernel threads 206 include kernel-level threads that operate entirely on operating system functions inside of operating system 120, as well as lightweight process threads 207 that are associated with user threads 208. User threads 208 are used to execute user programs. In the embodiment illustrated in FIG. 2, multiple user threads 208 can be mapped onto a single lightweight process thread 207.
Note that although a particular operating system structure is outlined in FIG. 2, the present invention applies to any operating system that allows multiple processes to work together on a single computational task.
Data Structures
FIG. 3 illustrates some of the data structures involved in implementing robust locks in accordance with an embodiment of the present invention. This embodiment illustrates process state 302, which contains state associated with a process that has access to mutex lock 308, such as process 122 from FIG. 1. Process state 302 includes state associated with process 122. This state is stored in a data structure (or data object) within operating system 120. For example, process state 302 includes a list of open files 304 for the process. Also included in process state 302 is lock registry 306, which includes a list of locks that may be in use by process 122. For example, in FIG. 3, lock registry 306 contains a pointer to mutex lock 308.
Lock registry 306 allows operating system 120 to determine if process 122 died while holding a lock. After a mutex lock 308 is initialized, it is registered in the lock registry 306 of any processes that desires to have access to mutex lock 308. For example, mutex lock 308 may be registered in lock registry 306 for process 122. This allows the operating system to determine and identify any locks that process 122 holds when and if process 122 dies. Note that lock registry 306 may alternatively reside outside of process state 302 in a separate lock registry table that is indexed by process identifier.
Mutex lock 308 contains state associated with a lock. This state includes lock flag 310, consistency flag 312, recoverability indicator 314 and lock type indicator 316. Lock flag 310 includes a byte or word of data indicating whether or not mutex lock 308 is locked. While mutex lock 308 is held by a process, lock flag 310 is set to a locked state so that other processes cannot acquire mutex lock 308. Consistency flag 312 indicates whether or not the program state protected by mutex lock 308 is consistent. Recoverability indicator 314 indicates whether or not the process state protected by mutex lock 308 is recoverable after a process holding mutex lock 308 dies. Finally, lock type indicator 316 indicates what type of lock mutex lock 308 is. For example, lock type indicator 316 may indicate whether mutex lock 308 is a robust lock or a non-robust lock.
Operation of Robust Locks
FIG. 4 is a flow chart illustrating how an operating system handles a process that dies while holding a mutex lock 308 in accordance with an embodiment of the present invention. In the illustrated flow chart, operating system 120 first receives a notification that a process 122 died (step 402). Operating system 120 examines a lock registry 306 within process state 302 to determine if process 122 died while holding mutex lock 308 (step 404). If so, operating system 120 marks the mutex lock 308 to indicate that a previous process died while holding mutex lock 308, and then unlocks mutex lock 308 by unmarking lock flag 310 in FIG. 3. This allows a subsequent process to grab mutex lock 308 and to determine that process 122 died while holding mutex lock 308.
Note that operating system 120 may indicate that a previous process died while holding mutex lock 308 by setting consistency flag 312 in FIG. 3 to an inconsistent state. Alternatively, consistency flag 312 may be set by a process that has acquired mutex lock 308 prior modifying the state protected by mutex lock 308. After this process has finished modifying the state protected by mutex lock 308, it unsets consistency flag 312.
FIG. 5 is a flow chart illustrating how a robust lock is used in accordance with an embodiment of the present invention. First, a process, such as process 122 from FIG. 1, makes a function call in an attempt to acquire a lock, such as mutex lock 308 from FIG. 3 (step 502). The function call examines lock flag 310 to determine if another process presently holds mutex lock 308. If another process currently holds mutex lock 308, process 122 blocks on mutex lock 308. When the other process ultimately releases mutex lock 308, process 122 acquires mutex lock 308 by marking lock flag 310 and the function call returns.
If the function call returns with no error value, the system performs the required work on the program state protected by the mutex lock 308 (step 514). After the required work is performed, the system releases mutex lock 308 by unmarking lock flag 310 so that another process can acquire mutex lock 308.
If the function call returns marked either “owner dead” or “lock unmapped,” the process knows that another process holding mutex lock 308 either died or became disassociated from mutex lock 308, and that the program state protected by mutex lock 308 may be in an inconsistent state. In this case, process 122 attempts to make the program state protected by mutex lock 308 consistent (step 504). If process 122 is able the make the program state consistent, it re-initializes mutex lock 308 and then unlocks mutex lock 308 (step 506). If process 122 is not successful in making the program state consistent, it marks mutex lock 308 as unrecoverable (by setting recoverability indicator 314 in FIG. 3) so that subsequent processes will know that process 122 failed to make the program state consistent (step 508). Process 122 will additionally unmark lock flag 310 to unlock mutex lock 308. This allows other processes to acquire mutex lock 308. Process 122 may also wake up processes that are waiting on mutex lock 308.
If the function call returns marked “unrecoverable” (i.e., recoverability indicator 314 from FIG. 3 is marked), process 122 knows that a previous process has already attempted to make the program state protected by mutex lock 308 consistent. Process 122 attempts to work around the inconsistent program state by, for example, repeating program operations that were required to produce the program state to begin with, or alternatively by restarting the program from the beginning (step 510). When this task is complete, process 122 destroys mutex lock 308 (step 512) and reinitializes mutex lock 308 so that another process can acquire mutex lock 308 (step 512).
Example of Using Robust Lock
Tables 1A and 1B present an example in the C programming language of how one embodiment of robust locks is used. The first portion of the main program (in Table 1A) initializes the mutex lock. The second portion of the main program (in Table 1B) includes a loop that cycles through a “switch” statement. This switch statement handles the three cases of “owner dead,” “not recoverable” and “no error,” which correspond to the three-way branch in the flow chart of FIG. 5.
TABLE 1A
/* Copyright ® 1998 SUN Microsystems, Inc. All Rights Reserved */
/* cc thisfile.c -lthread */
/* To execute, run the command line “a.out & a.out 1″ */
#include <sys/types.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <stdio.h>
#include <thread.h>
#define INTERPROCESS_FILE “ipc-sharedfile”
typedef struct {
mutex_t Interprocess_mutex;
int Interprocess_data;
} buffer_t;
buffer_t *buffer;
int make_date_consistent( );
void create_shared_memory( );
int zeroed[sizeof(buffer_t)];
int ipc_fd, i=0;
main(int argc, char *argv[]) {
int rc;
if (argc > 1) {
while((ipc_fd = open(INTERPROCESS_FILE,
O_RDWR)) == −1)
sleep(1);
buffer = (buffer_t*) mmap(NULL, sizeof(buffer_t),
PROT_READ[PROT_WRITE, MAP_SHARED,
ipc_fd, 0);
mutex_init(&buffer->Interprocess-mutex,
USYNC_PROCESS_ROBUST, 0);
} else {
create_shared_memory();
ipc_fd = open(INTERPROCESS_FILE, O_RDWR);
buffer = (buffer_t *) mmap(NULL, sizeof(buffer_t),
PROT_READ | PROT_WRITE, MAP_SHARED,
ipc_fd, 0);
buffer−>Interprocess_data = 0;
mutex_init(&buffer−>Interprocess_mutex,
USYNC_PROCESS_ROBUTS, 0);
}
TABLE 1B
/* Copyright ® 1998 SUN Microsystems, Inc. All Rights Reserved */
for(;;) {
rc = mutex_lock (&buffer−>Interprocess_mutex);
switch (rc) {
case EOWNERDEAD:
/*lock acquired.
* last owner died holding the lock, try
* to make the state associated with the
* mutex consistent.
* if so, make the robust lock consistent
* by re-initializing it.
*/
if (make_data_consistent( ))
mutex_init
(&buffer−>Inpterprocess_mutex,
USYNC_PROCESS ROBUST, 0);
mutex_unlock
(&buffer−>Interprocess_mutex);
case ENOTRECOVERABLE:
/*Lock not acquired.
* last owner got the mutex with
* EOWNERDEAD mutex is not con-
* sistent (and data?), so return.
*/
exit(1);
break;
case 0:
/* no error - data is consistent */
/* do something with data */
mutex_unlock
(&buffer−>Interprocess_mutex);
break;
}
}
} /* end main */
void create_shared memory( ) {
int i;
ipc_fd =
creat(INTERPROCESS_FILE,
O_CREAT | O_RDWR);
for (i=0; i<sizeof(buffer_t); i++) {
zeroed[i] = 0;
write(ipc_fd, &zeroed[i], 2);
}
close(ipc_fd);
chmod(INTERPROCESS_FILE,
S_IRWXU | S_IRWXG | S_IRWXO);
/* return 1 if able to make data consistent, otherwise 0 */
int make-data consistent ( ) {
buffer−>Interprocess_data = 0;
return (1);
}
The foregoing descriptions of embodiments of the invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the invention. The scope of the invention is defined by the appended claims.

Claims (20)

What is claimed is:
1. A method for providing robust recovery in the event a previous process holding a lock used for mutual exclusion purposes loses ownership of the lock, the loss of ownership occurring due to the previous process dying or the lock becoming unmapped, the method comprising:
making an attempt to acquire the lock; and
if the attempt to acquire the lock returns with an error indicating that the previous process holding the lock lost ownership of the lock,
attempting to make program state protected by the lock consistent,
if the attempt to make the program state consistent is successful, reinitializing the lock and unlocking the lock, and
if the attempt to make the program state consistent is not successful, marking the lock as unrecoverable so that subsequent processes attempting to acquire the lock receive an error indicating the lock is not recoverable.
2. The method of claim 1, further comprising if the attempt to acquire the lock returns without an error condition:
manipulating the program state protected by the lock, and
releasing the lock.
3. The method of claim 1, further comprising:
receiving a notification in an operating system that a process died;
determining if the process died while holding a lock; and
if the process died while holding the lock,
marking the lock to indicate to subsequent acquirers of the lock that a previous holder of the lock died, and
unlocking the lock so that other processes may acquire the lock.
4. The method of claim 1, further comprising if the attempt to acquire the lock returns with an error indicating the lock is not recoverable,
performing operations to work around the program state that is inconsistent, and
reinitializing the lock.
5. The method of claim 1, wherein the act of marking the lock as unrecoverable further comprises waking up processes waiting on the lock, so that the processes waiting on the lock will subsequently attempt to acquire the lock and will receive the error indicating the lock is not recoverable.
6. The method of claim 1, wherein the lock resides in a memory that is shared by a plurality of processes.
7. The method of claim 1, wherein the lock resides in a file that is shared by a plurality of processes.
8. The method of claim 1, wherein the lock resides in a location that can be directly accessed by a plurality of processes without performing an operating system call.
9. A method for providing robust recovery in the event a previous process holding a lock used for mutual exclusion purposes loses ownership of the lock, the loss of ownership occurring due to the previous process dying or the lock becoming unmapped, the method comprising:
receiving a notification in an operating system that a process died;
determining if the process died while holding the lock;
if the process died while holding the lock,
marking the lock to indicate to subsequent acquirers of the lock that a previous holder of the lock lost ownership of the lock, and
unlocking the lock so that other processes may acquire the lock;
making an attempt to acquire the lock;
if the attempt to acquire the lock returns with an error indicating that the previous process holding the lock lost ownership of the lock,
attempting to make program state protected by the lock consistent,
if the attempt to make the program state consistent is successful, reinitializing the lock and unlocking the lock, and
if the attempt to make the program state consistent is not successful, marking the lock as unrecoverable so that subsequent processes attempting to acquire the lock receive an error indicating the lock is not recoverable; and
if the attempt to acquire the lock returns without an error condition,
manipulating the program state protected by the lock, and
releasing the lock.
10. The method of claim 9, further comprising if the attempt to acquire the lock returns with an error indicating the lock is not recoverable,
performing operations to work around the program state that is inconsistent, and
reinitializing the lock.
11. The method of claim 9, wherein the act of marking the lock as unrecoverable further comprises waking up processes waiting on the lock, so that the processes waiting on the lock will subsequently attempt to acquire the lock, and will receive the error indicating the lock is not recoverable.
12. The method of claim 9, wherein the lock resides in a location that can be directly accessed by a plurality of processes without performing an operating system call.
13. A computer readable storage medium storing instructions that when executed by a computer cause the computer to perform a method for providing robust recovery in the event a previous process holding a lock used for mutual exclusion purposes loses ownership of the lock, the loss of ownership occurring due to the previous process dying or the lock becoming unmapped, the method comprising:
making an attempt to acquire the lock;
if the attempt to acquire the lock returns with an error indicating that the previous process holding the lock lost ownership of the lock,
attempting to make program state protected by the lock consistent,
if the attempt to make the program state consistent is successful, reinitializing the lock and unlocking the lock,
if the attempt to make the program state consistent is not successful, marking the lock as unrecoverable so that subsequent processes attempting to acquire the lock receive an error indicating the lock is not recoverable.
14. An apparatus for providing robust recovery in the event a previous process holding a lock used for mutual exclusion purposes loses ownership of the lock, the loss of ownership occurring due to the previous process dying or the lock becoming unmapped, the apparatus comprising:
a lock acquiring mechanism that makes an attempt to acquire the lock;
a consistency recovery mechanism that attempts to make program state protected by the lock consistent if the attempt to acquire the lock returns with an error indicating that the previous process holding the lock lost ownership of the lock;
a lock re-initialization mechanism that reinitializes the lock and unlocks the lock if the attempt to make the program state consistent is successful; and
a first lock marking mechanism that marks the lock as unrecoverable if the attempt to make the program state consistent is not successful, so that subsequent processes attempting to acquire the lock receive an error indicating the lock is not recoverable.
15. The apparatus of claim 14, further comprising a second lock marking mechanism within an operating system, wherein upon receiving a notification that a process died, the second lock marking mechanism determines if the process died while holding a lock, and if the process died while holding the lock, marks the lock to indicate to subsequent acquirers of the lock that a previous holder of the lock died, and unlocks the lock so that other processes may acquire the lock.
16. The apparatus of claim 14, further comprising a program recovery mechanism, wherein in the case where the attempt to acquire the lock returns with an error indicating the lock is not recoverable, the program recovery mechanism
performs operations to work around the program state that is inconsistent, and
reinitializes the lock.
17. The apparatus of claim 14, wherein the lock resides in a location that can be directly accessed by a plurality of processes without performing an operating system call.
18. A computer readable storage medium containing a lock data structure that facilitates providing robust recovery in the event a previous process holding the lock loses ownership of the lock, the loss of ownership occurring due to the previous process dying or the lock becoming unmapped, the data structure comprising:
a lock flag indicating whether the lock is locked; and
a recoverability indicator indicating that a second process was unable to make program state protected by the lock consistent after a first process holding the lock lost ownership of the lock.
19. The computer readable storage medium containing a lock data structure of claim 18, including a flag indicating whether the program state protected by the lock is in a consistent state.
20. The computer readable storage medium containing a lock data structure of claim 18, including a lock type indicator indicating whether the lock is a robust lock that includes a recoverability indicator.
US09/235,881 1999-01-22 1999-01-22 Robust and recoverable interprocess locks Expired - Lifetime US6301676B1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US09/235,881 US6301676B1 (en) 1999-01-22 1999-01-22 Robust and recoverable interprocess locks
EP00200223A EP1028378A3 (en) 1999-01-22 2000-01-20 Robust and recoverable interprocess locks
JP2000013313A JP4327972B2 (en) 1999-01-22 2000-01-21 Robust and recoverable interprocess lock

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/235,881 US6301676B1 (en) 1999-01-22 1999-01-22 Robust and recoverable interprocess locks

Publications (1)

Publication Number Publication Date
US6301676B1 true US6301676B1 (en) 2001-10-09

Family

ID=22887265

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/235,881 Expired - Lifetime US6301676B1 (en) 1999-01-22 1999-01-22 Robust and recoverable interprocess locks

Country Status (3)

Country Link
US (1) US6301676B1 (en)
EP (1) EP1028378A3 (en)
JP (1) JP4327972B2 (en)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6499048B1 (en) 1998-06-30 2002-12-24 Sun Microsystems, Inc. Control of multiple computer processes using a mutual exclusion primitive ordering mechanism
US6574749B1 (en) * 1999-10-29 2003-06-03 Nortel Networks Limited Reliable distributed shared memory
US20040025160A1 (en) * 2002-08-05 2004-02-05 David Dice System and method for maintaining data synchronization
US20040054861A1 (en) * 2002-09-17 2004-03-18 Harres John M. Method and tool for determining ownership of a multiple owner lock in multithreading environments
US6742135B1 (en) * 2000-11-07 2004-05-25 At&T Corp. Fault-tolerant match-and-set locking mechanism for multiprocessor systems
US20040225922A1 (en) * 2003-05-09 2004-11-11 Sun Microsystems, Inc. System and method for request routing
US20040225915A1 (en) * 2003-05-09 2004-11-11 Hewlett-Packard Development Company, L.P. Minimum latency reinstatement of database transaction locks
US20050022202A1 (en) * 2003-07-09 2005-01-27 Sun Microsystems, Inc. Request failover mechanism for a load balancing system
US20050022047A1 (en) * 2003-07-21 2005-01-27 Oracle International Corporation Conditional data access after database system failure
US20050066064A1 (en) * 2003-09-19 2005-03-24 International Business Machines Corporation Fault tolerant mutual exclusion locks for shared memory systems
US20050187891A1 (en) * 2004-02-06 2005-08-25 Johnson Charles S. Transaction processing apparatus and method
US20060288144A1 (en) * 2005-06-16 2006-12-21 Chan Wilson W S Techniques for handling lock-related inconsistencies
US20070240015A1 (en) * 2005-12-08 2007-10-11 International Business Machines Corporation Method for safely interrupting blocked work in a server
US7287258B1 (en) * 2001-08-31 2007-10-23 International Business Machines Corporation Thread consistency support system and method
US20090138758A1 (en) * 2005-09-09 2009-05-28 International Business Machines Corporation Method and system to execute recovery in non-homogeneous multi processor environments
US20090307526A1 (en) * 2007-03-12 2009-12-10 Fujitsu Limited Multi-cpu failure detection/recovery system and method for the same
US7925631B1 (en) * 2007-08-08 2011-04-12 Network Appliance, Inc. Method and system for reporting inconsistency of file system persistent point in time images and automatically thawing a file system
US20110161540A1 (en) * 2009-12-22 2011-06-30 International Business Machines Corporation Hardware supported high performance lock schema
US8682876B2 (en) * 2012-04-03 2014-03-25 Sas Institute, Inc. Techniques to perform in-database computational programming
US20160041882A1 (en) * 2014-08-07 2016-02-11 Microsoft Corporation Safe data access following storage failure
US9847918B2 (en) 2014-08-12 2017-12-19 Microsoft Technology Licensing, Llc Distributed workload reassignment following communication failure

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6622163B1 (en) * 2000-03-09 2003-09-16 Dell Products L.P. System and method for managing storage resources in a clustered computing environment

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5136704A (en) * 1989-06-28 1992-08-04 Motorola, Inc. Redundant microprocessor control system using locks and keys
US5305448A (en) * 1990-07-02 1994-04-19 International Business Machines Corp. Shared access serialization featuring second process lock steal and subsequent write access denial to first process
US5734817A (en) * 1995-03-01 1998-03-31 Unisys Corporation Method for making a data base available to a user program during data base recovery

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5623670A (en) * 1995-02-17 1997-04-22 Lucent Technologies Inc. Method and apparatus for crash safe enforcement of mutually exclusive access to shared resources in a multitasking computer system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5136704A (en) * 1989-06-28 1992-08-04 Motorola, Inc. Redundant microprocessor control system using locks and keys
US5305448A (en) * 1990-07-02 1994-04-19 International Business Machines Corp. Shared access serialization featuring second process lock steal and subsequent write access denial to first process
US5734817A (en) * 1995-03-01 1998-03-31 Unisys Corporation Method for making a data base available to a user program during data base recovery

Cited By (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6499048B1 (en) 1998-06-30 2002-12-24 Sun Microsystems, Inc. Control of multiple computer processes using a mutual exclusion primitive ordering mechanism
US6574749B1 (en) * 1999-10-29 2003-06-03 Nortel Networks Limited Reliable distributed shared memory
US6742135B1 (en) * 2000-11-07 2004-05-25 At&T Corp. Fault-tolerant match-and-set locking mechanism for multiprocessor systems
US20040205392A1 (en) * 2000-11-07 2004-10-14 Yuguang Wu Generic fault-tolerant locking mechanism for multiprocessor systems
US7171581B2 (en) * 2000-11-07 2007-01-30 At&T Corp. Fault-tolerant match-and-set locking mechanism for multiprocessor systems
US7536582B1 (en) * 2000-11-07 2009-05-19 At&T Corp. Fault-tolerant match-and-set locking mechanism for multiprocessor systems
US7287258B1 (en) * 2001-08-31 2007-10-23 International Business Machines Corporation Thread consistency support system and method
US20040025160A1 (en) * 2002-08-05 2004-02-05 David Dice System and method for maintaining data synchronization
US7200846B2 (en) 2002-08-05 2007-04-03 Sun Microsystems, Inc. System and method for maintaining data synchronization
US6886081B2 (en) 2002-09-17 2005-04-26 Sun Microsystems, Inc. Method and tool for determining ownership of a multiple owner lock in multithreading environments
US20040054861A1 (en) * 2002-09-17 2004-03-18 Harres John M. Method and tool for determining ownership of a multiple owner lock in multithreading environments
US7571354B2 (en) * 2003-05-09 2009-08-04 Sun Microsystems, Inc. System and method for request routing
US7100076B2 (en) * 2003-05-09 2006-08-29 Hewlett-Packard Development Company, L.P. Minimum latency reinstatement of database transaction locks
US20040225915A1 (en) * 2003-05-09 2004-11-11 Hewlett-Packard Development Company, L.P. Minimum latency reinstatement of database transaction locks
US20040225922A1 (en) * 2003-05-09 2004-11-11 Sun Microsystems, Inc. System and method for request routing
US20050022202A1 (en) * 2003-07-09 2005-01-27 Sun Microsystems, Inc. Request failover mechanism for a load balancing system
US7284151B2 (en) * 2003-07-21 2007-10-16 Oracle International Corporation Conditional data access after database system failure
US20050022047A1 (en) * 2003-07-21 2005-01-27 Oracle International Corporation Conditional data access after database system failure
US20050066064A1 (en) * 2003-09-19 2005-03-24 International Business Machines Corporation Fault tolerant mutual exclusion locks for shared memory systems
US20080243850A1 (en) * 2003-09-19 2008-10-02 Michael Maged M Fault tolerant mutual exclusion locks for shared memory systems
US7493618B2 (en) * 2003-09-19 2009-02-17 International Business Machines Corporation Fault tolerant mutual exclusion locks for shared memory systems
US8234646B2 (en) * 2003-09-19 2012-07-31 International Business Machines Corporation Fault tolerant mutual exclusion locks for shared memory systems
US7168001B2 (en) * 2004-02-06 2007-01-23 Hewlett-Packard Development Company, L.P. Transaction processing apparatus and method
US20050187891A1 (en) * 2004-02-06 2005-08-25 Johnson Charles S. Transaction processing apparatus and method
US7315910B2 (en) * 2005-06-16 2008-01-01 Oracle International Corporation Techniques for handling lock-related inconsistencies
US20060288144A1 (en) * 2005-06-16 2006-12-21 Chan Wilson W S Techniques for handling lock-related inconsistencies
US7765429B2 (en) * 2005-09-09 2010-07-27 International Business Machines Corporation Method and system to execute recovery in non-homogenous multi processor environments
US20090138758A1 (en) * 2005-09-09 2009-05-28 International Business Machines Corporation Method and system to execute recovery in non-homogeneous multi processor environments
US7788529B2 (en) * 2005-12-08 2010-08-31 International Business Machines Corporation Method for safely interrupting blocked work in a server
US20070240015A1 (en) * 2005-12-08 2007-10-11 International Business Machines Corporation Method for safely interrupting blocked work in a server
TWI413000B (en) * 2005-12-08 2013-10-21 Ibm Method,system and storage medium for safely interrupting blocked work in a server
US8074123B2 (en) * 2007-03-12 2011-12-06 Fujitsu Limited Multi-CPU failure detection/recovery system and method for the same
US20090307526A1 (en) * 2007-03-12 2009-12-10 Fujitsu Limited Multi-cpu failure detection/recovery system and method for the same
US7925631B1 (en) * 2007-08-08 2011-04-12 Network Appliance, Inc. Method and system for reporting inconsistency of file system persistent point in time images and automatically thawing a file system
US20110161540A1 (en) * 2009-12-22 2011-06-30 International Business Machines Corporation Hardware supported high performance lock schema
US8682876B2 (en) * 2012-04-03 2014-03-25 Sas Institute, Inc. Techniques to perform in-database computational programming
US20160041882A1 (en) * 2014-08-07 2016-02-11 Microsoft Corporation Safe data access following storage failure
US9665432B2 (en) * 2014-08-07 2017-05-30 Microsoft Technology Licensing, Llc Safe data access following storage failure
US10545831B2 (en) 2014-08-07 2020-01-28 Microsoft Technology Licensing, Llc Safe data access following storage failure
US9847918B2 (en) 2014-08-12 2017-12-19 Microsoft Technology Licensing, Llc Distributed workload reassignment following communication failure
US11228510B2 (en) 2014-08-12 2022-01-18 Microsoft Technology Licensing, Llc Distributed workload reassignment following communication failure

Also Published As

Publication number Publication date
EP1028378A2 (en) 2000-08-16
EP1028378A3 (en) 2004-03-17
JP4327972B2 (en) 2009-09-09
JP2000215070A (en) 2000-08-04

Similar Documents

Publication Publication Date Title
US6301676B1 (en) Robust and recoverable interprocess locks
US6546443B1 (en) Concurrency-safe reader-writer lock with time out support
US7395383B2 (en) Realtime-safe read copy update with per-processor read/write locks
US5862376A (en) System and method for space and time efficient object locking
EP0747815B1 (en) Method and apparatus for avoiding dealocks by serializing multithreaded access to unsafe resources
US8020160B2 (en) User-level read-copy update that does not require disabling preemption or signal handling
US8185704B2 (en) High performance real-time read-copy update
US8234646B2 (en) Fault tolerant mutual exclusion locks for shared memory systems
US9218307B2 (en) Reader-writer synchronization with high-performance readers and low-latency writers
US7747996B1 (en) Method of mixed lock-free and locking synchronization
US9207997B2 (en) Multithreaded lock management
EP0532333A2 (en) A system and method for preventing deadlock in a multiprocessor environment
US7444634B2 (en) Method and apparatus for providing dynamic locks for global resources
JPH1115793A (en) Protection method for resource maintainability
JP4620871B2 (en) Monitor conversion in multi-threaded computer systems
US7793023B2 (en) Exclusion control
EP0889396A1 (en) Thread synchronisation via selective object locking
US6366946B1 (en) Critical code processing management
US7681197B1 (en) Nested monitor handling processes
US20210342202A1 (en) Critical Section Speedup Using Help-Enabled Locks
US7305508B2 (en) Semaphoring system between system firmware and hardware manipulation subsystem
JP3422504B2 (en) Exclusive control method between tasks
JP3764282B2 (en) Control device for program control system
Barton et al. Beyond Threads: Resource Sharing in UNIX.
Bressler Software Transactional Memory in the Linux Kernel

Legal Events

Date Code Title Description
AS Assignment

Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUMAR, ASWINI S.;STEIN, DANIEL A.;REEL/FRAME:009732/0993;SIGNING DATES FROM 19981228 TO 19990114

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12

AS Assignment

Owner name: ORACLE AMERICA, INC., CALIFORNIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037278/0579

Effective date: 20100212