Patent Application
20080005741
The purposes and advantages of the present invention will be apparent from the following detailed description in conjunction with the appended figures of drawings in which:
In the various figures of the drawings, like references are used to denote like or similar elements or steps.
Preferred embodiments of the present invention are hardware mutexes (HWMs). As illustrated in the various drawings herein, and particularly in the views of
Two implementations of an accelerated HWM are now described. The first is a “dedicated” HWM which uses a simpler hardware implementation but requires that hardware resources be dedicated for each critical software task that is being protected. The second is a “shared” HWM which uses a more complex implementation that can share a limited pool of mutex resources amongst many critical software tasks. Finally, the handling of some common mutex usages, such as priority inversion and nested mutexes, are discussed as they relate to the inventive accelerated HWMs.
In both implementations, the inventor prefers to take care to only accelerate non-contending mutex operations. While it is certainly possible to completely implement all facets of OS type mutex behavior in hardware, it is felt that the additional complexity brings only minor performance improvements while significantly increasing cost and stability.
The Dedicated Hardware Mutex (HWM)
In an optional step 102 an executing software task first sets optional parameters into processor registers or other locations that are well-known to the OS. Some examples of such parameters are wait timeout values, and block versus non-blocking flags. In a step 104 the software task next sets a mutex lock bit in the lock command register 14, and in an optional step 106 wait states can be inserted to prevent the software task from executing instructions while the mutex controller 12 evaluates and acts on the lock request.
Separately, in a step 108 the mutex controller 12 monitors the lock command register 14 to determine the state of the dedicated HWM 10 (i.e., whether it has been requested to lock). If not, in a step 110 the mutex controller 12 sets the locked flag 20 (but does not assert the mutex controller interrupt 24). That is, it “silently” sets the flag and execution of the software task simply continues, with no interruption, at the instruction following the mutex lock process 100 (and any optional wait states) (i.e., at a step 112). Alternately, however, if it is determined in step 108 that the dedicated HWM 10 has already been locked, in a step 114 the mutex controller 12 sets the waiters flag 22 and in a step 116 asserts the mutex controller interrupt 24.
A step 118 here depicts where the software task becomes “aware” that it has been interrupted. Of course, if the mutex controller 12 has not asserted the mutex controller interrupt 24, the software task simply “sees” step 112 next.
If the mutex controller interrupt 24 was asserted, however, in a step 120 that causes execution of the software task to divert to the interrupt exception handler of its processor (the processor running that software task, if multiple processors are present). Here the interrupt exception handler saves the state of the processor, including the parameters left in registers by the calling software task (back in step 102). In a step 122 control then passes to an interrupt service routine (ISR) in the mutex controller 12, where the OS kernel is invoked using a semaphore or other OS primitive. In a step 124 the OS kernel then handles the rest of the request to lock the dedicated HWM 10 in software, referring to the saved parameters stored for the state of the processor to enable options such as dealing with lock timeouts, blocking versus non-blocking, and priority inversions. After handling the lock request in step 124, the OS scheduler locates the highest priority software task that is currently in a runnable state, and in a step 126 execution continues with that task.
In a step 202 an executing software task sets a mutex (un) lock bit in the unlock command register 16 and in an optional step 204 wait states can be inserted to prevent the software task from executing instructions while the mutex controller 12 evaluates and acts on the unlock request.
Separately, in a step 206 the mutex controller 12 monitors the state of the waiters flag 22 to determine if there are any software tasks waiting to lock the dedicated HWM 10. If the waiters flag 22 is not set, in a step 208 the mutex controller 12 clears the locked flag 20 (but does not assert the mutex controller interrupt 24). That is, it “silently” resets the flag and execution of the software task simply continues, with no interruption, at the instruction following the mutex unlock process 200 (and any optional wait states) (i.e., at a step 210). Alternately, however, if it is determined in step 206 that the waiters flag 22 is set, in a step 212 the mutex controller 12 asserts the mutex controller interrupt 24.
A step 214 here depicts where the software task becomes “aware” that it has been interrupted. Of course, here as well, if the mutex controller 12 has not asserted the mutex controller interrupt 24, the software task simply “sees” step 210 next.
If the mutex controller interrupt 24 was asserted, however, in a step 216 this causes execution of the software task to divert to the interrupt exception handler of its processor (the processor running that software task, if multiple are present). Here the interrupt exception handler saves the state of the processor. In a step 218 control then passes to an interrupt service routine (ISR) associated with the mutex controller 12 where the OS kernel is invoked using a semaphore or other OS primitive. In a step 220 the OS kernel then handles the rest of the request to unlock the dedicated HWM 10 in software. Optionally, if there are no other software tasks waiting to lock the dedicated HWM 10, in a step 222 the OS kernel can also clear the waiters flag 22, by setting a clear bit in the clear waiter command register 18 that the mutex controller 12 monitors for. After handling the unlock request in step 220, the OS scheduler locates the highest priority software task that is currently in a runnable state, and in a step 224 execution continues with that task.
The Shared Hardware Mutex (HWM)
When mutex accelerator capability is available, it is seemingly desirable to have as many mutexes as is possible, so that all shared resource protection can be accelerated. However, given that a complex system may have hundreds or even thousands of unique shared resources, providing an individual HWM for each shared resource can become burdensome. Also, since most mutexes protect against multiple access conditions to shared resources which rarely occur, dedicated hardware for this would be rarely used and could be mostly wasted.
If a given mutex is not locked by any software task, the only useful state that it carries is its unique identification, which is shared between all the software tasks that might lock it. Also, at any particular time, a typical computerized system will only have a few active critical software tasks that have locked mutexes. So, given that only locked mutexes are interesting and that there are very few of them at any particular time, it is the inventor's observation that a mutex cache can be created that tracks only locked mutexes. This approach then gives the appearance of an almost unlimited number of HWMs, yet requires only a small pool of hardware mutex structures.
The lock command register 304 is written with a mutex ID value by a software task seeking to create a locked mutex, and the unlock command register 306 is written to by a software task to provided for unlocking a locked mutex.
The heart of the shared HWM 300 is a locked mutex cache 316, which looks very similar to a memory cache. The locked mutex cache 316 contains a list of mutex ID tags 318 which identify the cached locked mutexes. However, instead of lines of cache memory corresponding to the mutex ID tags 318, the locked mutex cache 316 also holds a list of waiter flags 320, one for each mutex ID tag 318. These waiter flags 320 are used to flag mutexes that have multiple lock requests outstanding.
The clear waiter command register 308 permits clearing a waiter flag 320 for a particular locked mutex. The interrupt on free flag 310 can be set to force an interrupt any time that an entry becomes free in the locked mutex cache 316.
The mutexes controller interrupt 312 and the active mutex register 314 are the two main outputs. The mutexes controller interrupt 312 signals the OS whenever software assistance is required from the OS kernel, and the active mutex register 314 identifies the cached mutex entry related to an assertion of the mutexes controller interrupt 312.
Similar to operation of the dedicated HWM 10, in an optional step 402 here as well an executing software task first sets optional parameters into processor registers or other locations that are well-known to the OS. Some examples of such parameters are wait timeout values, and block versus non-blocking flags. In a step 404 the software task next writes a unique mutex ID into the lock command register 304, and in an optional step 406 wait states can be inserted to prevent the software task from executing instructions while the mutexes controller 302 evaluates and acts on the lock request.
The mutex ID needs to be unique for every possible shared resource in the computerized system. For instance, it can be implemented as a system memory address, which would allow mutexes corresponding to any data structure in the system to be uniquely protected with any level of access granularity, even down to individual bytes. Memory-mapped hardware controller registers can also be seamlessly protected. Alternately, in a computerized system where virtual memory is in use and physical system memory addresses are not available, a process identifier can be added to a logical address in order to create a unique mutex ID.
Separately, in a step 408 the mutexes controller 302 monitors the lock command register 304 to determine the state of the shared HWM 300 (i.e., whether a mutex with the same ID has already been locked). If not, in a step 410 the mutexes controller 302 determines if there is space in the locked mutex cache 316.
If there is space, in a step 412 the mutex ID (from the lock command register 304) is stored in an empty slot in the locked mutex cache 316 as a new mutex ID tag 318. Execution of the current software task then simply continues with no interruption, at the instruction following the mutex lock process 400 (and any optional wait states) (i.e., at a step 414).
Alternately, however, if the locked mutex cache 316, is already filled with mutex ID tags 318 for locked mutexes, in a step 416 the mutexes controller 302 sets the active mutex register 314 to indicate an error condition and in a step 418 it asserts the mutexes controller interrupt 312.
Otherwise, if the mutexes controller 302 has determined back in step 408 that it did find a mutex ID tag 318 corresponding with the mutex ID in the lock command register 304, in a step 420 the mutexes controller 302 loads the mutex ID into the active mutex register 314, in a step 422 it asserts the mutexes controller interrupt 312, and in a step 424 it sets a waiters flag 320 for that mutex ID tag 318 in the locked mutex cache 316.
A step 426 here depicts where the software task becomes “aware” that it has been interrupted. Of course, if the mutexes controller 302 has not asserted the mutexes controller interrupt 312, the software task simply “sees” step 414 next.
If the mutexes controller interrupt 312 was asserted (in either step 418 or step 422), in a step 428 this causes execution of the software task to divert to the interrupt exception handler of its processor (the processor running that software task, if multiple processors are present). The interrupt exception handler then saves the state of the processor, including the parameters left in registers by the calling software task (back in step 402). In a step 430 control then passes to an interrupt service routine (ISR) in the mutexes controller 302, where the OS kernel is invoked using a semaphore or other OS primitive.
In a step 432 the OS kernel will then read the active mutex register 314 and determine if it indicates an error condition (set in step 416). If an error is indicated, the OS will know that the locked mutex cache 316 is full and in a step 436 it will create a software mutex for the mutex ID that was written to the lock command register 304. Since the locked mutex cache 316 now no longer contains mutex ID tags 318 for all of the active mutexes, in a step 436 the OS sets the interrupt on free flag 310 so that mutex cache coherency can be maintained when interleaved locks and unlocks are done on multiple mutexes.
Otherwise, if the active mutex register 314 did not indicate an error condition in step 432, mutex contention is indicated and in a step 438 the OS will handle the mutex lock request in software, referring to the parameters stored in step 402 about the calling tasks' state, to enable options such as lock timeouts, blocking vs. non-blocking, and priority inversion. Finally, after handling the lock request, in a step 440 the OS scheduler locates the highest priority task that is in a runnable state, and execution continues with that software task.
In a step 502 an executing software task writes a mutex ID into the in the unlock command register 306 and in an optional step 504 wait states can be inserted to prevent the software task from executing instructions while the mutexes controller 302 evaluates and acts on the unlock request.
Separately, in a step 506 the mutexes controller 302, which is monitoring the unlock command register 306, receives the mutex ID and searches for an entry for it in the locked mutex cache 316.
If the mutex ID is not found, in a step 508 the mutexes controller 302 simply asserts the mutexes controller interrupt 312 to force software handling of the unlock request. If a mutex ID tag 318 corresponding to the mutex ID is found, however, in a step 510, the mutexes controller 302 checks whether its associated waiters flag 320 is set.
If the waiters flag 320 is set, this indicates that there are other tasks waiting to lock the mutex for the particular resource, and in step 508 (again) the mutexes controller interrupt 312 is now asserted to allow the OS to handle the unlock request. If the waiters flag 320 is not set, however, in a step 512 the mutexes controller 302 clears the entry for the present mutex ID tag 318 from the locked mutex cache 316. Then, in a step 514 the mutexes controller 302 checks the state of the interrupt on free flag 310.
If the interrupt on free flag 310 is set, in step 508 (again) the mutexes controller 302 asserts the mutexes controller interrupt 312. If the interrupt on free flag 310 is not set, however, software execution simply continues, with no interruption, at the instruction following the mutex unlock process 500 (and any optional wait states) (i.e., at a step 516).
A step 518 here depicts where the software task becomes “aware” that it has been interrupted. Of course, here as well, if the mutexes controller 302 has not asserted the mutexes controller interrupt 312, the software task simply “sees” step 516 next.
If the mutexes controller interrupt 312 was asserted, however, in a step 520 this causes execution of the software task to divert to the interrupt exception handler of its processor (the processor running that software task, if multiple are present). Here the interrupt exception handler saves the state of the processor. In a step 522 control then passes to an interrupt service routine (ISR) associated with the mutexes controller 302, where the OS kernel is invoked using a semaphore or other OS primitive. In a step 524 the OS kernel then handles the rest of the request to unlock the shared HWM 300 in software. Optionally, if there are no other software tasks waiting to lock the resource associated with the present mutex ID tag 318, in a step 526 the OS kernel can also clear the waiters flag 320. Also optionally, if all software mutexes have been unlocked or have been transferred back into the locked mutex cache 316, in a step 528 the OS kernel can also clear the interrupt on free flag 310. Finally, after handling the unlock request in step 524, the OS scheduler locates the highest priority software task that is currently in a runnable state, and in a step 530 execution continues with that task.
Some General Considerations for the Hardware Mutexes (HWMs)
The handling of nested mutex locks can be handled in various manners, as a matter of design preference in embodiments of the inventive hardware mutex, such as the dedicated HWM 10 and the shared HWM 300. Some OSes support nested locking of mutexes, or “counting” mutexes, where the same software task can lock a mutex that it already has locked. The approach described above for the dedicated HWM 10 and the shared HWM 300 force the nested locks to be handled in software, since this otherwise would require the addition of a lock counter and an “owning task ID” for each mutex, as well as adding significant complexity to the mutex controller 12 or the mutexes controller 302. Adding this complexity is an option, but it is not the present inventor's preferred approach. Instead it is recommended that any mutexes requiring nesting continue to be supported in software rather than be adding hardware to support such “corner cases.” The inventive hardware mutex is, however, still flexible enough to use in conditions where occasional nesting will occur. Usually the fast hardware-based lock/unlock approach will be followed then, with occasional invocations of the OS to handle the nested operations in software.
Accordingly, returning now to the needs discussed in the Background Art section, it can now be appreciated that the inventive hardware mutex provides a mechanism that eliminates the lock and unlock overhead under non-contending conditions in the kernel of an OS, and that significantly reduces the burden of handling contention when it does occur. Notably, the hardware mutex permits doing this without disabling processor interrupts to check and manage mutexes. And under the hardware mutex priority inversions can be handled naturally, since the OS always gains control when a lock is attempted on a mutex that is already in the locked state and the OS lock routine can handle the priority inversion in its usual manner.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and that the breadth and scope of the invention should not be limited by any of the above described exemplary embodiments, but should instead be defined only in accordance with the following claims and their equivalents.
The inventive hardware mutex, of which the dedicated HWM 10 and the shared HWM 300 are embodiments, is well suited for application in modern computer systems where multiple software tasks (or threads of execution in a same software process) must contend for access to shared single-access hardware resources. As has been described herein, the hardware mutex enables the locking and unlocking of critical sections in software process (i.e., the individual software tasks) with little or no overhead imposed on the operating system (OS) kernel.
For example, of particular importance today in the field of emerging portable computerized devices, the inventive hardware mutex reduces the power requirements of multi-threaded real-time operating system (RTOS) when many mutex operations are performed at low clock rates. This applies especially when most heavy processing is done with hardware accelerators and the RTOS processor acts mostly in a caretaker role. The overall system interrupt latency is then also improved by reducing or eliminating the frequency and duration of software critical sections which are usually implemented by disabling processor interrupts. This then may allow dropping the processor clock rate even further.
The hardware mutex also greatly simplifies the handling of hardware resources, by generally permitting mutex locks and waiters to be tracking within each hardware entity. For a lock operation, the OS only needs to be interrupted when a mutex is already locked, otherwise saving the locked state of the mutex silently with processor execution of the software task continuing with no interruption or critical section handling. Similarly, for an unlock operation, the OS only needs to be interrupted when a mutex has waiters, otherwise clearing the locked state of the mutex silently with execution proceeding with no interruption or critical section handling. The hardware mutex leaves mutex parameters in processor registers for the OS to collect if and only when lock fails and the OS gains control, thus reducing the interrupts that prior art approaches would require when a software task is blocked. Optionally, the inventive hardware mutex can be embodied to handle nested mutexes in such a way that commonly used un-nested operations are dealt with quickly by hardware, while barely used nested operations are supported by the OS.
Furthermore, while the inventive hardware mutex has been described herein with respect to applications having clear and wide immediate need, the hardware mutex can be extended by one of ordinary skill in the art once the teachings herein are appreciated. For instance, the hardware mutex can be generalized to support a generic counting semaphore. The mutex use case may produce more needless trips through the OS kernel than other semaphore use cases, but this approach may still have utility in some situations. Or the inventive hardware mutex can be hooked up to multiple processors, each with its own mutex lock/unlock/waiter registers and corresponding interrupt signals to arbitrate multi-processor mutexes. A register indicating the processor that triggered the mutex interrupt can be added to improve efficiency, although the same implementation can be done entirely in software on each processor if desired.
For the above, and other, reasons, it is expected that the hardware mutex of the present invention will have widespread industrial applicability and it is therefore expected that the commercial utility of the present invention will be extensive and long lasting.
This is a continuation-in-part of application Ser. No. 11/427,015, filed 28 Jun. 2006, hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11427015 | Jun 2006 | US |
| Child | 11461755 | US |
