Abstract:
In general, this disclosure describes techniques of ensuring cache coherency in a multi-processor computing system. More specifically, a relaxed coherency mechanism is described that provides the appearance of strong coherency and consistency to correctly written software executing on the multi-processor system. The techniques, as described herein, combine software synchronization instructions with certain hardware-implemented instructions to ensure cache coherency.

Description:
TECHNICAL FIELD 
     The invention relates to computer memory caches, and particularly to memory cache coherency. 
     BACKGROUND 
     Multiple processors in a multiprocessor computing system may share a common memory. This common memory may store data and/or instructions utilized by the processors in the multiprocessor computing system. In order to improve access time to the common memory, the multiprocessor computing system may be designed such that caches are associated with each of the processors. These caches may store data and/or instructions retrieved from the common memory by individual ones of the processors and may store data to be written to the common memory by the processors. 
     Cache coherency issues may arise when one or more of the caches store its own copy of data associated with a memory location in the common memory. For example, a first processor in the multiprocessor system may be associated with a first cache and a second processor in the multiprocessor system may be associated with a second cache. The first cache may store a copy of data at memory address 0x66 of the common memory and the second cache may also store a copy of data at memory address 0x66 of the common memory. In this example, a cache coherency issue may arise when the first processor writes new data to memory address 0x66. When the first processor writes new data to memory address 0x66, the copy of the data at memory address 0x66 that is stored in the second cache is now obsolete. In other words, the first cache and the second cache are no longer coherent with respect to memory address 0x66. If the second processor were to use this obsolete copy of the data, the second processor may perform an incorrect behavior. 
     Typical multiprocessor computing systems include hardware to prevent cache coherency issues. For example, multiprocessor computing systems may implement a directory-based cache coherence mechanism. In a directory-based cache coherence mechanism, a multiprocessor computing system maintains a directory that specifies which caches contain which data. Cache controllers reference the directory when updating data within a cache to ensure the update is made within the other caches. In another example, multiprocessor computing systems may implement a snooping cache coherence mechanism. In a snooping cache coherence mechanism, a centralized hardware component, or each cache, monitors address lines to detect accesses to common memory locations. When a given cache detects a write request to a memory address that the cache has currently cached, the cache may invalidate a cache block in the cache associated with the memory address. 
     Implementations of directory-based and snooping cache coherence mechanisms may require significant amounts of hardware. As a result, multiprocessor computing systems that implement either of these cache coherence mechanisms may consume significant amounts of additional electrical power and/or may be physically larger. 
     SUMMARY 
     In general, this disclosure describes techniques of ensuring cache coherency in a multi-processor computing system. More specifically, a relaxed coherency mechanism is described that provides the appearance of strong coherency and consistency to correctly written software executing on the multi-processor system. The techniques, as described herein, combine software synchronization instructions with certain hardware-implemented instructions to ensure cache coherency. 
     The techniques take advantage of operating system-level process synchronization calls typically found within software applications executing on the multi-processor system in order to serialize access to shared memory. These process synchronization calls indicate when changes to shared memory become visible to the other software applications. In accordance with the techniques described herein, process synchronization services implementing the process synchronization calls have been modified to include cache coherence instructions supported by the processors. That is, the processors support an enhanced instruction set that has been extended to include additional hardware support for cache coherence instructions. In response to process synchronization calls from software applications, the process synchronization services may perform process synchronization operations and additionally invoke cache coherence instructions. 
     In one embodiment, a method comprises executing a first software process on a first processor in a multi-processor computing system. The first software process comprises a sequence of instructions that includes a process synchronization kernel call instruction. The method also comprises executing a first operating system (OS) instance on the first processor. In addition, the method comprises executing a process synchronization kernel service of the first OS instance with respect to a resource associated with one or more memory locations of a shared memory when the first processor executes the process synchronization kernel call instruction. The process synchronization kernel service comprises a sequence of instructions that includes a cache coherence instruction. The shared memory is shared among the first processor and at least one other processor in the multi-processor computing system. The method also comprises executing, with the first processor, the cache coherence instruction that is included in the sequence of instructions of the process synchronization kernel service. When the first processor executes the cache coherence instruction, the first processor outputs signals that enforce cache coherence among caches associated with processors in the multi-processor computing system with respect to the one or more memory locations associated with the resource. 
     In another embodiment, a multi-processor computing system comprises a first processor that executes a first OS instance and that executes a first software process. In addition, the multi-processor computing system comprises a second processor that executes a second OS instance. The multi-processor computing system also comprises a shared memory having memory locations that store data. The shared memory is utilized by the first processor and the second processor. In addition, the multi-processor computing system comprises a first cache that stores data that the first processor has read from the memory and data that the first processor has written to the shared memory. Furthermore, the multi-processor computing system comprises a second cache that stores data that the second processor has read from the memory and data that the second processor has written to the shared memory. The first processor includes hardware to execute cache coherence instructions. When the first processor executes a process synchronization kernel call instruction in the first software process, the first processor executes instructions of a process synchronization kernel service of the first OS instance with respect to a resource associated with one or more memory locations of the shared memory. When the first processor executes a cache coherence instruction in the process synchronization kernel service, the first processor outputs signals that enforce cache coherence among the first cache and the second cache with respect to the one or more memory locations associated with the resource. 
     In another embodiment, a computer-readable medium comprises instructions. When executed, the instructions cause a first processor in a multi-processor computing system to execute instructions of a first software process on a first processor in a multi-processor computing system. The first software process comprises a sequence of instructions that includes a process synchronization kernel call instruction. The instructions also cause the first processor to execute a first OS instance on the first processor. In addition, the instructions cause the first processor to execute a process synchronization kernel service of the first OS instance with respect to a resource that is associated with one or more memory locations of a shared memory when the first processor executes the process synchronization kernel call instruction. The process synchronization kernel service comprises a sequence of instructions that includes a cache coherence instruction. The shared memory is shared among the first processor and at least one other processor in the multi-processor computing system. The instructions also cause the first processor to execute the cache coherence instruction that is included in the sequence of instructions of the process synchronization kernel service. When the first processor executes the cache coherence instruction, the first processor outputs signals that enforce cache coherence among caches associated with processors in the multi-processor computing system with respect to the memory locations associated with the resource. 
     The techniques described in this disclosure may provide one or more advantages. For example, the techniques may provide similar programmability and portability benefits as strong cache coherence in other multiprocessor systems. However, a system implementing these techniques may require fewer hardware resources than traditional multi-processor systems using hardware-based techniques to ensure strong cache coherency. Furthermore, these techniques do not require any additional instructions within user processes. 
     The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG. 1  is a block diagram illustrating an exemplary multi-processor computing system. 
         FIG. 2  is a block diagram illustrating an exemplary software stack. 
         FIG. 3  is a flowchart that illustrates an example operation a process. 
         FIG. 4  is a flowchart illustrating an example operation of a lock kernel service. 
         FIG. 5  is a flowchart illustrating an example operation of an unlock kernel service. 
         FIG. 6  is a flowchart illustrating an exemplary operation of a processor. 
         FIG. 7  is a flowchart illustrating an exemplary operation of a cache controller. 
         FIG. 8  is flowchart illustrating an exemplary operation of a lock manager. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram illustrating an exemplary multi-processor computing system  2 . Several concepts are needed to describe a release cache coherent multiprocessor computing system. These concepts include the following: 
     Program: A u-program is a programmer-specified sequence of instructions that executes on a single processor. An m-program is the collection of u-programs that execute on the multiprocessor. 
     Program order: The program order, is a total order among the instructions of a u-program as specified by the next instruction relation in the u-program. Instructions from u-programs running on different processors are not comparable by program order. 
     Process: A “u-process” is the sequence of instructions executed from a u-program on a processor. An m-process is the collection of u-processes that result from the execution of the respective u-programs on the multiprocessor. 
     Execution order: The “execution order” is a total order among the instructions of a u-process based on instruction execution completion. Unlike program order, instructions from u-processes on different processors in the multiprocessor system may be comparable by execution order based on values observed in shared memory. Thus, while no instructions in an m-program are comparable by program order, some instructions in an m-process may be comparable by execution order. 
     Synchronization order: Synchronization operations op 1  and op 2  executed by processors P i  and P j  are in synchronization order in an m-process, if op 1  completes before op 2  in the m-process. 
     Happens-before order: A “happens-before” order for a multi-processor computing system is a partial order defined for the execution of a set of processes through an irreflexive transitive closure of the program order for the set of programs and the “synchronization order” for the set of processes. 
     Data race: Two operations by processors P i  and P j  in a multi-processor computing system constitute a “data race” in an execution of a set of processes when both of the operations are write operations to the same memory location and the operations are not ordered by “happens-before” order in the set of processes. 
     Using these concepts, a multi-processor computing system is defined herein as “release coherent” if and only if: 
     (a) every write operation issued by a processor in the multi-processor computing system eventually completes with respect to all processors in the computing system if followed in program order by a release operation, 
     (b) a read operation by a processor P i  in the computing system returns a value of the last write to the same location issued by P i  that has not yet completed with respect to P i  or, if there is no such write by P i  then it returns the initial value of the memory location, and 
     (c) write operations to the same memory location complete in the same order with respect to every processor if the writes are not involved in a data race. 
     Computing system  2 , illustrated in the example of  FIG. 1 , may comprise a network server, an intermediate network device, a personal computer, a laptop computer, a video game platform or console, a graphics processing unit, a network appliance, a supercomputer, a computer integrated into a vehicle, a robotic device, a mobile radiotelephone, a point-of-sale device, a mainframe computer, or another type of computing system. 
     Computing system  2  may include processors  4 A through  4 N (collectively, “processors  4 ”). Processors  4  may comprise general-purpose microprocessors, application-specific integrated circuits, digital signal processors, or other types of integrated circuits. For example, processors  4  may comprise Core processors manufactured by Intel Corp. of Santa Clara, Calif. An inter-processor bus  17  may facilitate communication among processors  4  and a lock manager  14 . 
     Furthermore, computing system  2  may include a shared memory  6 . Shared memory  6  may comprise a Synchronous Dynamic Random Access Memory, a Direct Rambus Dynamic Random Access Memory, a Double Data Rate 2 or 3 Synchronous Random Access Memory, or another type of random access memory. 
     Each of processors  4  may be associated with one or more of caches  8 A through  8 N (collectively, “caches  8 ”). As illustrated in the example of  FIG. 1 , processor  4 A may be associated with cache  8 A, processor  4 B may be associated with cache  8 B, and so on. 
     Caches  8  may comprise storage units that cache data that processors  4  read from or write to a shared memory  6 . In other words, caches  8  store copies of data read from and written to shared memory  6 . In some circumstances, caches  8  may store copies of all data in shared memory  6 . A memory bus  16  facilitates communication between caches  8  and shared memory  6 . 
     Each of caches  8  may represent an individual cache block. A cache block may be subdivided into a plurality of cache zones. Each cache zone may be subdivided into a plurality of cache sectors. A cache sector may store data associated with several contiguous memory locations. For example, each cache sector may store sixteen bytes. Moreover, each cache sector may be aligned on a 16 byte boundary. If a cache sector associated with a memory location stores data that is different than data stored at the memory location in shared memory  6 , this disclosure may refer to this cache sector as “dirty.” Likewise, if a cache sector associated with a memory location stores data that is not different than data stored at the memory location in shared memory  6 , this disclosure may refer to this cache sector as “clean.” Each cache sector in caches  8  may be associated with a status bit that indicates whether a particular cache sector is “dirty” or “clean.” 
     Furthermore, caches  8 A through  8 N may include cache controllers  12 A through  12 N (collectively, “cache controllers  12 ”). Each of cache controllers  12  may comprise one or more integrated circuits that control the operations of one of caches  8  in response to signals from processors  4  and other ones of cache controllers  12 . An inter-cache bus  13  facilitates communication among cache controllers  12 . 
     Each of processors  4  executes software instructions of computer programs. For example, processors  4  may execute instructions of an operating system, execute instructions of an end-user software application, or execute instructions of another type of computer program. Because processors  4  use shared memory  6 , data corruption in shared memory  6  may occur if programs executed by processors  4  are not properly synchronized. For example, if programs executed by processors  4  are not properly synchronized, a first program may cause processor  4 A to read data from a memory location in shared memory  6  while a second program may cause processor  4 B to attempt to write data to the same memory location in shared memory  6 . As a result, processor  4 A may receive some of the old data in the memory location and some of the data that processor  4 B is writing to the memory location. Because the data received by processor  4 A is neither the old data nor the new data, processor  4 A may perform in unexpected ways. 
     To avoid synchronization problems, such as that described in the previous paragraph, processes may include process synchronization kernel call instructions. When one of processors  4  executes a process synchronization kernel call instruction in a process, the operating system suspends the process and performs a process synchronization kernel service provided by that instance of the operating system executing on the processor. A process synchronization kernel service may comprise a sequence of instructions that cause a processor to perform a process synchronization operation. For example, a first process may include a process synchronization kernel call instruction. When processor  4 A executes the process synchronization kernel call instruction, processor  4 A may suspend the first process and begin executing instructions of a process synchronization kernel service. 
     The instructions of process synchronization kernel services may include instructions that cause processors  4  to use inter-processor bus  17  to send one or more messages to lock manager  14 . These messages may instruct lock manager  14  to acquire or to release a lock on one or more resources. A resource may be a data structure stored in one or more memory locations. For example, a resource may be an array of thirty integers. A name of a resource (i.e., a resource name) is an identifier that used by processes to identify a shared resource. For example, a process executing on processor  4 A and a process executing on processor  4 B may use the name “integerArray30” to refer to the resource in the previous example. 
     Lock manager  14  may comprise an integrated circuit such as a microprocessor, an application-specific integrated circuit, a digital signal processor, or another type of integrated circuit. Lock manager  14  may maintain a lock table  9  in shared memory  6 . Lock table  9  may specify whether resources are locked. For example, lock table  9  may specify that a process has acquired a lock on resource “integerArray30”. 
     The instructions of process synchronization kernel services may also include cache coherence instructions. When processors  4  execute cache coherence instructions, the cache coherence instructions cause the processors to output respective ones of signals  15 A through  15 N (collectively, “signals  15 ”) that enforce cache coherence among caches  8 . As explained in detail below, cache coherence instructions may cause processors  4  to output signals  15  to cache controllers  12 . When one of cache controllers  12  receives one of signals  15 , the cache controller may copy updated data from the cache to shared memory  6  and may output signals via inter-cache bus  13  that instruct the other cache controllers to invalidate cache sectors associated with the updated data. 
     The techniques described in this disclosure may provide one or more advantages. For example, the techniques may provide a simple mechanism to enforce the release coherency of caches  8 . Moreover, because the techniques rely on software applications to invoke process synchronization kernel services that, when executed, invoke cache coherence instructions, there may be no need to track in hardware whether to invalidate sectors of caches  8 . This may contribute to a simpler hardware design that saves energy, production costs, and development costs. Furthermore, because process synchronization kernel services may include the cache coherence instructions, there may be no need for a process that uses the process synchronization kernel services to include cache coherence instructions. In other words, execution of the cache coherence instructions is transparent to a process that includes a process synchronization kernel call instruction. Because the execution of the cache coherence instructions is transparent to the process, the process does not need to include the cache coherence instructions in order to enforce release coherency. 
       FIG. 2  is a block diagram illustrating an exemplary software stack. As illustrated in the example of  FIG. 2 , a process  18 A operates within an operating environment provided by an operating system (OS) instance  20 A. OS instance  20 A operates within an operating environment provided by processor  4 A ( FIG. 1 ). In other words, process  18 A may utilize services provided by OS instance  20 A and processor  4 A. OS instance  20 A may utilize services provided by processor  4 A. 
     OS instance  20 A may comprise a sequence of instructions that, when executed by processor  4 A, cause processor  4 A to provide a distributed real-time operating system. Process  18 A may comprise a sequence of instructions that, when executed by processor  4 A, cause processor  4 A to perform a software application. Process  18 A may represent a process of a multi-process software application (i.e., a u-process of an m-process). Such a multi-process software application may cause processors  4  to perform a wide variety of computing tasks. For instance, the multi-process software application may detect network attacks in network traffic that flows to computing system  2 . A network attack may comprise a computer virus, spyware, an attempt to gain unauthorized access to information, or another type of security threat that is embodied in network traffic. Alternatively, process  18 A may not cause processor  4 A to interact with instances of a same computer program executing on other ones of processors  4 . 
     Processor  4 A includes instruction set support hardware  25 A to execute various software instructions. For example, instruction set support hardware  25 A may include circuitry to execute arithmetic instructions (e.g., add, multiply, divide, subtract, etc.) and logical instructions (e.g., and, or, not, exclusive or, etc.). Furthermore, instruction set support hardware  25 A may include hardware to execute cache coherence instructions. As illustrated in the example of  FIG. 2 , instruction set support hardware  25 A includes update cache coherence hardware  27 A to execute “update” cache coherence instructions and flush cache coherence hardware  28 A to execute “flush” cache coherence instructions. 
     Process  18 A includes a lock kernel call instruction  19 A that specifies a name of a resource. When processor  4 A executes lock kernel call instruction  19 A, instructions of OS instance  20 A may suspend process  18 A and cause processor  4 A to execute the instructions of lock kernel service  22 A provided by OS instance  20 A. The instructions of lock kernel service  22 A may cause processor  4 A to determine whether there is already a lock on the resource specified by the process synchronization kernel call. For example, the instructions of lock kernel service  22 A may cause processor  4 A to output one or more messages to lock manager  14  via inter-processor bus  17 . These messages may include the resource name specified by lock kernel call instruction  19 A. When lock manager  14  receives these messages, lock manager  14  may determine whether a process has acquired a lock on a resource indicated by the resource name. If a process has already acquired a lock on the resource indicated by the resource name, lock manager  14  may send a message to processor  4 A instructing OS instance  20 A to block process  18 A (e.g., cause the process to sleep) until a lock on the specified resource has been released. If no process has acquired a lock on the resource indicated by resource name, lock manager  14  may update lock table  9  to indicate that a process has acquired a lock on the resource indicated by the resource name and allows process  18 A to continue operating. Consequently, whenever another process requests a lock on this resource, this other process is blocked until process  18 A releases the lock. 
     Process  18 A may include a process synchronization kernel call instruction  26 A for a so-called “try-lock” process synchronization kernel service provided by OS instance  20 A. When processor  4 A executes “try-lock” process synchronization kernel call instruction  26 A that specifies a particular resource, instructions of OS instance  20 A may cause processor  4 A to suspend process  18 A and to execute the instructions of a “try-lock” process synchronization kernel service  29 . The instructions of “try-lock” process synchronization kernel service  29  may cause lock manager  14  to determine whether a process has already acquired a lock on the specified resource. If no process has acquired a lock on the specified resource, lock manager  14  may update lock table  9  to indicate that a process has acquired a lock on the specified resource. However, if lock manager  14  determines that another process has already acquired a lock on the specified resource, lock manager  14  does not cause process  18 A to be blocked. Rather, process  18 A may continue to operate. Thus, the “try-lock” synchronization kernel service may be used to implement a so-called “spin lock” in which the invoking process actively waits for the lock to be released. A “spin lock” may be useful when it is possible for a process to perform work while the process is waiting for a lock to become available. 
     While process  18 A has a lock on a resource, the instructions of process  18 A may cause processor  4 A to initiate one or more read operations that read data from a memory location associated with the resource and to initiate one or more write operations that write data to a memory location associated with the resource. When the instructions of process  18 A cause processor  4 A to initiate a read operation, processor  4 A may read the data from cache  8 A before attempting to read the data from shared memory  6 . When the instructions of process  18 A cause processor  4 A to initiate a write operation to write data to a memory location, the write operation does not write the data to the memory location in shared memory  6 . Rather, when the instructions of process  18 A cause processor  4 A to initiate a write operation for the memory location, the write operation updates the data associated with the memory location in cache  8 A. 
     The instructions of process  18 A also include an unlock kernel call instruction  21 A that specifies a resource name. When processor  4 A executes unlock kernel call instruction  21 A, instructions of OS instance  20 A may cause processor  4 A to suspend process  18 A and to execute the instructions of an unlock kernel service  24 A in OS instance  20 A. 
     The instructions of unlock kernel service  24 A include a cache coherence instruction  23 A. Cache coherence instruction  23 A may be an “update” cache coherence instruction or a “flush” cache coherence instruction. When processor  4 A executes the either a “update” cache coherence instruction or a “flush” cache coherence instruction, update cache coherence hardware  27 A or flush cache coherence hardware  28 A of processor  4 A may output signals  15 A to cache controller  12 A. Signals  15 A enforce cache coherence among caches  8  with respect to the memory addresses specified as operands of the cache coherence instructions. The specified memory addresses may be the memory addresses associated with a resource indicated by the resource name specified by unlock kernel call instruction  21 A. 
     Cache coherence instruction  23 A may specify groups of memory addresses at various levels of cache granularity. For instance, cache coherence instruction  23 A may specify memory addresses at the “cache sector” level of cache granularity, memory addresses at the “cache zone” level of granularity, or memory addresses at the “cache block” level of cache granularity. When processor  4 A executes an update cache coherence instruction, update cache coherence hardware  27 A may output signals that enforce cache coherence among caches  8  with respect to memory locations at the specified level of cache granularity. 
     When processor  4 A executes an “update” cache coherence instruction that specifies a particular memory address at the “cache sector” level of cache granularity, update cache coherence hardware  27 A may output signal  15 A to cache controller  12 A. When cache controller  12 A receives signal  15 A, cache controller  12 A may identify a cache sector in cache  8 A that is associated with the memory address. Next, cache controller  12 A may determine whether a status indicator of the identified cache sector indicates that the identified cache sector is “dirty.” If the status indicator of the identified cache sector indicates that the identified cache sector is “dirty,” cache controller  12 A may copy data in the identified cache sector to the memory location in shared memory  6 . After cache controller  12 A copies the data in the identified cache sector, cache controller  12 A may update the status indicator of the identified cache sector to indicate that the identified cache sector is “clean.” Next, cache controller  12 A may send “invalidate” messages to cache controllers  12 B through  12 N via inter-cache bus  13 . The “invalidate” messages may instruct cache controllers  12 B through  12 N to invalidate cache sectors in caches  8 B through  8 N that are associated with the memory address. 
     When processor  4 A executes an “update” cache coherence instruction that specifies one or more cache zones, update cache coherence hardware  27 A may output signal  15 A to cache controller  12 A. When cache controller  12 A receives signal  15 A, cache controller  12 A may identify cache sectors in the specified cache zones that have status indicators that indicate that cache sectors are “dirty.” After identifying the “dirty” cache sectors, cache controller  12 A may copy data in the identified cache sectors to memory locations of shared memory  6  that are associated with the identified cache sectors. Next, cache controller  12 A may send “invalidate” messages to cache controllers  12 B through  12 N via inter-cache bus  13 . The “invalidate” messages may instruct cache controllers  12 B through  12 N to invalidate, in cache zones of caches  8 B through  8 N that are equivalent to the specified cache zones, cache sectors that are associated with memory locations that associated with the “dirty” sectors. 
     When processor  4 A executes an “update” cache coherence instruction that specifies a cache block, update cache coherence hardware  27 A may output one or more signals to cache controller  12 A. When cache controller  12 A receives the signals, cache controller  12 A may first identify cache sectors in cache  8 A that are “dirty.” Cache controller  12 A may then copy data in each of the identified cache sectors to memory locations of shared memory  6  that are associated with the identified cache sectors: After copying the data, cache controller  12 A may send “invalidate” messages to cache controllers  12 B through  12 N via inter-cache bus  13 . The “invalidate” messages may instruct cache controllers  12 B through  12 N to invalidate cache sectors of caches  8 B through  8 N that are associated with memory locations that are associated with the identified sectors of cache  8 A. 
     When processor  4 A executes a “flush” cache coherence instruction, flush cache coherence hardware  28 A may output one or more signals to cache controller  12 A. When cache controller  12 A receives the signals, cache controller  12 A may perform an operation that is similar to the operation that cache controller  12 A performs when cache controller  12 A receives signals from update cache coherence hardware  27 A, as described in the preceding paragraphs. However, when cache controller  12 A receives the signals from flush cache coherence hardware  28 A, cache controller  12 A may invalidate “dirty” cache sectors in all of caches  8 . For example, when processor  4 A executes a “flush” cache coherence instruction that specifies a particular cache sector, flush cache coherence hardware  28 A may output signals  15 A that cause cache controller  12 A to copy data in the specified cache sector to shared memory  6  if the cache sector is “dirty.” After copying the data to shared memory  6 , cache controller  12 A may invalidate the specified cache sector in cache  8 A and broadcast “invalidate” messages to cache controller  12 B through  12 N in order to invalidate equivalent cache sectors in caches  8 B through  8 N. Like update cache coherence instructions, flush cache coherence instructions may be invoked with regard to cache blocks, cache sectors, cache zones, or other levels of granularity. 
     Data races may result when processes are written such that more than one resource may be stored in one cache sector. That is, in order to avoid data races, processes should be written such that no two resources may be stored within one cache sector. Two operations by two of processors  4  constitute a data race in an execution if the two operations are both write operations and the two operations are not ordered by a “happens-before” order in a set of processes that use a common memory location or cache sector. 
     To illustrate why processes should not be written such that more than one resource may be stored in one cache sector, consider the following example. A first process operating on processor  4 A and a second process operating on processor  4 B may cooperate to perform a computing task. The first process and the second process may use two resources: resource A and resource B. Resource A may be a data structure that stores data at memory addresses  4  and  20  in a byte addressable memory architecture (i.e., each addressable memory location stores a single byte). Resource B may be a data structure that stores data at memory addresses  28  and  36 . As discussed above, each cache sector in caches  8  may store sixteen bytes. In this example, caches  8 A and  8 B may both include first cache sectors that store data associated with memory addresses  0 - 15 , second cache sectors that store data associated with memory addresses  16 - 31 , and third cache sectors may store data associated with memory addresses  32 - 47 . Therefore, the data of resource A be stored in the first cache sectors and the second cache sectors and the data of resource B may be stored in the second cache sectors and the third cache sectors. 
     Continuing the example of the previous paragraph, the first process may acquire a lock on resource A and the second process may acquire a lock on resource B. The first process may acquire a lock on resource A and the second process may acquire a lock on resource B because lock manager  14  uses resource names, not cache sectors, to determine whether a process has already acquired a lock. Because the first process has acquired a lock on resource A, the first process may write data to memory address  20 . When the first process writes data to memory address  20 , the cache sector associated with memory addresses  16 - 31  in cache  8 A is marked as “dirty.” Furthermore, because the second process has acquired a lock on resource B, the second process may write data to memory address  28 . When the second process writes data to memory address  28 , the cache sector associated with memory addresses  16 - 31  in cache  8 B is marked as “dirty.” 
     After writing the data to memory address  20 , the first process may invoke unlock kernel service  24 A to release the lock on resource A. As described above, the instructions of unlock kernel service  24 A may include an “update” cache coherence instruction or a “flush” cache coherence instruction. When processor  4 A executes the “update” cache coherence instruction or the “flush” cache coherence instruction, update cache coherence hardware  27 A or flush cache coherence hardware  28 A may output signals  15 A to cache controller  12 A that instruct cache controller  12 A to update or to flush cache sectors associated with memory addresses  0 - 15  and cache sectors associated with memory addresses  16 - 31 . When cache controller  12 A receives signals  15 A, cache controller  12 A may broadcast “invalidate” messages in order to invalidate cache sectors associated with memory addresses  0 - 15  and cache sectors associated with memory addresses  16 - 31 . When cache controller  12 B receives the message to invalidate cache sectors associated with memory addresses  16 - 31 , cache controller  12 B may detect that the cache sector of cache  8 B associated with memory addresses  16 - 31  is “dirty.” The fact that cache controller  12 B received an “invalidate” message for cache sectors that are “dirty” indicates that a data race has occurred. If cache controller  12 B were to invalidate the cache sector associated with memory addresses  16 - 31 , the data written to memory address  28  would be lost and the second process would have no way of knowing that this data had been lost. This may cause the second process to function in an incorrect manner. 
     When any of cache controllers  12  detect a data race, the cache controller may output a signal to one of processors  4 . In response to this signal, the processor may provide an alert to the user of computing system  2 . The alert may help the user of computing system  2  to debug process  18 A. In particular, the alert may help the user of computing system  2  to reprogram processes such that the processes do not share resources that may be stored within one cache sector. 
     Processes may directly include cache coherence instructions. For example, process  18 A may be one thread of a single application. These threads may be programmed to be intentionally non-deterministic. In other words, the threads of the application may be intentionally asynchronous. Because the threads of the application are non-synchronous, the threads might not include process synchronization kernel calls. In this example, the threads may directly include cache coherence instructions in order to write data from caches  8  to shared memory  6 . 
       FIG. 3  is a flowchart that illustrates an example operation of process  18 A. Initially, the instructions of process  18 A may cause processor  4 A to perform one or more actions ( 30 ). For example, process  18 A may cause processor  4 A to perform a pattern matching operation. Later, a “lock” process synchronization kernel call instruction of process  18 A may cause processor  4 A to perform the instructions of lock kernel service  22 A ( 32 ). The “lock” process synchronization kernel call instruction may specify a resource name. The instructions of lock kernel service  22 A cause processor  4 A to output signals that cause cache controller  12 A to acquire a lock on a resource indicated by the specified resource name. 
     After processor  4 A executes “lock” process synchronization kernel call instruction  19 A, the instructions of process  18 A may cause processor  4 A to initiate one or more read or write operations to memory addresses associated with the resource ( 34 ). Subsequently, “unlock” process synchronization kernel call instruction  21 A of process  18 A may cause processor  4 A to perform the instructions of unlock kernel service  24 A ( 36 ). From the perspective of process  18 A, the instructions of unlock kernel service  24 A cause lock manager  14  to release the lock on the specified resource. Additional instructions of process  18 A may then cause processor  4 A to perform one or more additional actions ( 38 ). 
       FIG. 4  is a flowchart illustrating an example operation of lock kernel service  22 A. Initially, lock kernel call instruction  19 A in process  18 A may cause processor  4 A to execute instructions of lock kernel service  22 A ( 40 ). The instructions of lock kernel service  22 A cause processor  4 A to output one or more messages to lock manager  14  requesting a lock on a resource ( 42 ). 
     If another process has already acquired a lock on the resource (“YES” of  44 ), lock manager  14  may output a message to processor  4 A that causes instructions of OS instance  20 A in processor  4 A to block process  18 A until processor  4 A receives a signal from lock manager  14  that process  18  has acquired the lock on the resource ( 46 ). For instance, the instructions of OS instance  20 A may add process  18 A to a list of “suspended” processes. When a process is on the list of “suspended” processes, processor  4 A does not process instructions of the process. When process  18 A acquires the lock on the resource (“NO” of  44 ), processor  4 A may receive a lock identifier of the lock from lock manager  14  ( 48 ). When processor  4 A receives the lock identifier, the instructions of lock kernel call instruction  19 A may unblock process  18 A ( 50 ). For example, the instructions of lock kernel service  22 A may cause processor  4 A to remove the current process from the list of “suspended” processes and add the process to a list of “active” processes. 
       FIG. 5  is a flowchart illustrating an example operation of unlock kernel service  24 A. Initially, unlock kernel call instruction  21 A in process  18 A may cause processor  4 A to begin executing instructions of unlock kernel service  24 A ( 60 ). Unlock kernel call instruction  21 A may specify a resource name. When processor  4 A is executing the instructions of unlock kernel service  24 A, processor  4 A may execute cache coherence instruction  23 A in unlock kernel service  24 A ( 62 ) When processor  4 A executes cache coherence instruction  23 A, cache coherence instruction  23 A may cause processor  4 A to output signals  15 A that enforce cache coherence among caches  8 . After processor  4 A executes cache coherence instruction  23 A, the instructions of unlock kernel service  24 A may cause processor  4 A to output a message to lock manager  14  to cause lock manager  14  to release the lock on the resource indicated by the specified resource name ( 64 ). After causing processor  4 A to output this message, the instructions of unlock kernel service  24 A may cause processor  4 A to return control to process  18 A ( 66 ). 
       FIG. 6  is a flowchart illustrating an exemplary operation of processor  4 A. Initially, processor  4 A may retrieve a current instruction from a memory location indicated by a memory address stored in a program counter of processor  4 A ( 70 ). The current instruction may be an instruction of a “current process.” 
     When processor  4 A retrieves the current instruction, processor  4 A may determine whether the current instruction is an “update” cache coherence instruction ( 84 ). If the current instruction is an “update” cache coherence instruction (“YES” of  84 ), update cache coherence hardware  27 A in processor  4 A may output signals  15 A to cache controller  12 A ( 86 ). Signals  15 A instruct cache controller  12 A to perform an update cache coherence operation. After processor  4 A outputs signals  15 A to cache controller  12 A, processor  4 A may increment the program counter ( 88 ). Once processor  4 A has incremented the program counter, processor  4 A may loop back and retrieve the instruction from the memory location indicated by the memory address stored in the program counter of processor  4 A ( 70 ). 
     If the current instruction is not an “update” cache coherence instruction (“NO” of  84 ), processor  4 A may determine whether the current instruction is a “flush” cache coherence instruction ( 90 ). If the current instruction is a “flush” cache coherence instruction (“YES” of  90 ), processor  4 A may output signals  15 A to cache controller  12 A ( 92 ). Signals  15 A instruct cache controller  12 A to perform a flush cache coherence operation. After processor  4 A outputs signals  15 A to cache controller  12 A, processor  4 A increments the program counter ( 88 ). Once processor  4 A has incremented the program counter, processor  4 A may loop back and retrieve the instruction from the memory location indicated by the memory address stored in the program counter of processor  4 A ( 70 ). 
     If the current instruction is not a “flush” cache coherence instruction (“NO” of  90 ), processor  4 A may perform some other operation ( 94 ). For example, the current instruction may cause processor  4 A to perform an arithmetic operation. After performing the operation, processor  4 A may increment the program counter ( 88 ). Processor  4 A may then loop back and retrieve the instruction from the memory location indicated by the memory address stored in the program counter of processor  4 A ( 70 ). 
       FIG. 7  is a flowchart illustrating an exemplary operation of cache controller  12 A. Initially, cache controller  12 A may receive signal  15 A ( 100 ). When cache controller  12 A receives signal  15 A, cache controller  12 A may determine whether signal  15 A is an “invalidate” signal ( 102 ). If signal  15 A is an “invalidate” signal (“YES” of  102 ), cache controller  12 A may identify one or more cache sectors in cache  8 A that are indicated by the signal ( 104 ). After identifying the cache sectors, cache controller  12 A may determine whether any of the identified cache sectors are “dirty” ( 106 ). If any of the identified cache sectors are “dirty” (“YES” of  106 ), cache controller  12 A may output a signal that indicates that cache controller  12 A has detected a data race ( 110 ). Otherwise, if none of the identified cache sectors are “dirty” (“NO” of  106 ), cache controller  12 A may invalidate the identified cache sectors ( 108 ). 
     When signal  15 A is not an “invalidate” signal (“NO” of  102 ), cache controller  12 A may determine whether signal  15 A is a signal to perform a flush cache coherence operation ( 112 ). If signal  15 A is a signal to perform an flush cache coherence operation (“YES” of  112 ), cache controller  12 A may identify any “dirty” cache sectors of cache  8 A specified by signal  15 A ( 114 ). After identifying the “dirty” cache sectors, cache controller  12 A may write data in the “dirty” cache sectors to shared memory  6  ( 116 ). After writing the data to shared memory  6 , cache controller  12 A may invalidate cache sectors in cache  6 A specified by the signal ( 118 ). Cache controller  12 A may then broadcast “invalidate” messages to cache controllers  12 B through  12 N ( 126 ). These invalidate messages may also specify memory addresses associated with the “dirty” cache sectors. 
     If signal  15 A is not a signal to perform a flush cache coherence operation (“NO” of  112 ), cache controller  12 A may determine whether signal  15 A is a signal to perform an update cache coherence operation ( 120 ). If signal  15 A is a signal to perform an update cache coherence operation (“YES” of  120 ), cache controller  12 A may identify any “dirty” cache sectors of cache  8 A specified by signal  15 A ( 122 ). After identifying the “dirty” cache sectors, cache controller  12 A may write the “dirty” cache sectors to shared memory  6  ( 124 ). Next, cache controller  12 A may broadcast “invalidate” messages to cache controllers  12 B through  12 N ( 126 ). 
     If signal  15 A is not a signal to perform an update cache coherence operation (“NO” of  120 ), cache controller  12 A may output an error ( 128 ). 
       FIG. 8  is flowchart illustrating an exemplary operation of lock manager  14 . Initially, lock manager  14  receives a message from one of processors  4  via inter-processor bus  17  ( 150 ). 
     When lock manager  14  receives the message, lock manager  14  may determine whether the received message is an “acquire lock” message ( 152 ). If the received message is an “acquire lock” message (“YES” of  152 ), lock manager  14  may add a process identifier specified in the received message to a lock request queue ( 154 ). The process identifier may be a process identifier used within one of processors  4  concatenated with an identifier of the one of processors  4 . Next, lock manager  14  may determine whether another process has already acquired a lock on a resource specified by the received message ( 156 ). For example, lock manager  14  may use lock table  9  to determine whether other processes have already acquired locks on the resource specified by the received message. As discussed above, lock table  9  may indicate whether particular resources are locked. 
     If lock manager  14  determines that a Process has already acquired a lock on the specified resource (“YES” of  156 ), lock manager  14  may generate and send a message to the one of processors  4  that generated the received message ( 158 ). The message sent by lock manager  14  may instruct the processor to block the process that requested the lock. On the other hand, if lock manager  14  determines that the specified resource is not are locked (“NO” of  156 ), lock manager  14  may remove the process identifier of the requesting process from the lock request queue ( 160 ). Next, lock manager  14  may create a lock for the requesting process for the specified resources ( 162 ). For example, lock manager  14  may update lock table  9  to indicate that the requesting process holds a lock on the specified resources. After creating the lock, lock manager  14  may return an identifier of the lock to the processor of the requesting process ( 164 ). When the processor receives this signal, the processor may unblock the requesting process. 
     If the received message is not an “acquire lock” message (“NO” of  152 ), lock manager  13  may determine whether the received message is a “try-lock” message ( 166 ). If the received message is a “try-lock” message (“YES” of  166 ), lock manager  14  may determine whether another process has already acquired a lock on the resource specified by the “try-lock” message ( 168 ). If lock manager  14  determines that another process already holds a hold on the specified resource (“YES” of  168 ), lock manager  14  may generate and send a message to the one of processors  4  that generated the “try-lock” message ( 170 ). The message sent by lock manager  14  may instruct the processor that another process has already acquired a lock on the resource, but the processor may allow the process that originated the “try-lock” message to continue operating. On the other hand, if lock manager  14  determines that no other resource has acquired a lock on: the specified resource (“NO” of  168 ), lock manager  14  may create a lock for the requesting process for the specified resource ( 162 ). After creating the lock, lock manager  14  may return an identifier of the lock to the processor of the requesting process ( 164 ). 
     If the received message is not an “acquire try-lock” message (“NO” of  166 ), lock manager  14  may determine whether the received message is a “release lock” message ( 172 ). If the received message is a “release lock” message (“YES” of  172 ), lock manager  14  may release the lock specified in the “release lock” message ( 176 ). For example, a “release lock” message may include a lock identifier provided by lock manager  14  when lock manager  14  created the lock. In this example, lock manager  14  may update lock table  9  to release the lock identified by the lock identifier. After lock manager  14  releases the lock, lock manager  14  may determine whether there are any process identifiers in the lock request queue that are requesting a resource associated with the released lock ( 178 ). If there is no such process identifier in the lock request queue (“NO” of  178 ), lock manager  14  performs no further action ( 180 ). On the other hand, if there is such a process identifier in the lock request queue (“YES” of  178 ), lock manager  14  may remove this process identifier from the lock request queue ( 182 ). Next, lock manager  14  may create a lock for the process identified by the process identifier for the specified resource ( 162 ). For example, lock manager  14  may update lock table  9  to indicate that this process holds a lock on the specified resource. After creating the lock, lock manager  14  may return a message that specifies an identifier of the lock to the processor of this process ( 164 ). When the processor receives this message, the processor may unblock this process. 
     In one or more exemplary embodiments, the functions described may be implemented in hardware, software, and/or firmware, or any combination thereof. If implemented in hardware, the functions may be implemented in one or more microprocessors, microcontrollers, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or the like. Such components may reside within a communication system, data writing and/or reading system, or other systems. If implemented in software, the functions may be stored as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. A storage medium may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise random-access memory (RAM), read-only memory (ROM), electrically-erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Storage media may comprise computer program products. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, DVD optical discs, floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. 
     Various embodiments of the invention have been described. These and other embodiments are within the scope of the following claims.