Hardware assisted lease-based access to memory

[00002] 1. Field of the Invention

[00003] Embodiments of the present invention generally relate to memory systems. More particularly, embodiments of the present invention relate to the field of controlling access to the content of a memory.

[00004] 2. Related Art

[00005] The growing trend towards networked computers, computers having multiple CPUs (central processing unit), and multi-threaded software poses a number of challenges for memory systems. In particular, the memory systems need to respond to access requests (e.g., to read data, to write data, etc.) from various data users (e.g., computer1, computer2, CPU1, CPU2, software1, software2, etc.) for shared resources while maintaining coherency so that the multiple data users have a similar view of the content in the memory system. Several approaches have been implemented.

[00006] In one case, when implementing concurrent multi-threaded software, mutually exclusive access to certain data structures in the memory system is often needed in order to guarantee coherence and to avoid corrupting the data structures. Such mutual exclusion is traditionally implemented using semaphores, which are software flags that a thread may set to indicate that it needs exclusive access to the associated data structure. Other threads are expected to properly inspect and honor the semaphore (i.e., not try to access the data structure when the flag is already set.)

[00007] This works well when the software is behaved, but problems arise when the software has design defects or is not operating properly. If the software has design defects, one thread may end up monopolizing a particular semaphore forever, preventing others from accessing the associated data structure forever. Moreover, if the software has design defects or undetected bugs (or operates in a faulty manner), a thread may choose to not honor the semaphore and to proceed to access a data structure whose flag is already set by another thread. This may lead to data coherency problems.

[00008] Similarly, in an architecture having multiple CPUs or computers (each having one or more CPUs), there is a need for mutually exclusive access to particular data of the content in the memory system. Such mutual exclusion is generally implemented using a lock process. The lock process enables a CPU to obtain a lock on the particular data in the memory system so as to prevent other CPUs from having access to the particular data until the lock is released by the CPU holding it. Typically, any other CPU that needs to access the particular data waits until the lock is released or communicates with the CPU holding the lock to request the release of the lock.

[00009] In this case, the lock process is suitable if the CPUs are functioning properly. Generally, the memory lock process fails to prevent a misbehaving CPU from accessing content of a memory system due to a design defect or undetected bugs (or operates in a faulty manner) or a hardware malfunction in the CPU. Moreover, the lock process does not prevent a CPU from monopolizing a lock to the detriment of other CPUs.

[00010] In sum, these approaches are less than satisfactory in many instances because broken/overloaded CPUs or defective software are able to corrupt content (in the memory system) belonging to another CPU or software through a lock or a semaphore and also to monopolize content (in the memory system) forever after securing a lock or a semaphore, complicating error recovery.

[00011] A memory system is disclosed in which hardware assisted leases are utilized to control access to shared data resources among data users. The lease is a type of lock on content in the memory system that automatically expires after a preset period of time. The lease enables the lease owner exclusive use of the associated content in the memory system. Furthermore, the memory system has a memory access mechanism that is separate from the data users. The memory access mechanism includes hardware components to enforce lease-based access to the memory system. Since the lease expires rather than being permanently granted, no CPU or software thread is able to monopolize a lease forever. Moreover, since the lease-base access is hardware-assisted, faulty CPUs or software are prevented from unauthorized access to leased (or locked) content in which another CPU or software already holds a lease.

[00012] In an embodiment, the memory of the memory system includes leasable memory blocks. Moreover, the memory system includes a lease table which includes the leases, whereas each lease corresponds to a leasable memory block. In one embodiment, there are two types of memory in the memory system. The first type is the leasable data memory where data is stored and retrieved. The other type is the lease table which stores the information necessary to maintain the lease.

[00013] In particular, each lease includes a plurality of lease information. The lease information may include a lease owner identifier, lease expiration data, a lease status, and a pointer corresponding to a leasable memory block. The lease status may be one of a leased state, an unleased state, and a lease expired state. In addition, the lease status determines whether a lease can be acquired by a data user (e.g., CPU, software, etc.) wanting exclusive use of the content of the leasable memory block. Moreover, the lease information determines which data user is authorized to access the associated leasable memory block for a preset period of time.

[00014] In practice, the memory access mechanism controls and grants access to the content of the leasable memory blocks based on the lease information in the lease table. Since the address of each leasable memory block is included in the corresponding lease of the lease table, an unauthorized data user cannot access the leasable memory block without first securing the corresponding lease which would then provide the address or path to the leasable memory block.

[00015] Exemplary lease operations include lease_acquire, lease_release, lease_read, lease_write, and lease_inquire. These operations facilitate the lease-base access to memory.

[00016] These and other advantages of the present invention will no doubt become apparent to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments, which are illustrated in the drawing figures.

[00029] Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention.

[00030] Leases are utilized in a memory system to control access so as to maintain data resource coherency among multiple applications/processors. Since the lease expires rather than being permanently granted, no CPU or software thread is able to monopolize a lease forever. Moreover, since the lease-base access is hardware-assisted, faulty CPUs or software are prevented from unauthorized access to content in which another CPU or software already holds a lease.

[00031] FIG. 1 illustrates an exemplary memory system 100 in accordance with an embodiment of the present invention. The memory system 100 includes a memory access mechanism 50 and a memory 10 for storing a plurality of shared content (e.g., data, pointers, resources, etc.). In particular, the memory system 100 utilizes leases to control access to the content in the memory 10. The lease is a type of lock on content in the memory 10 that automatically expires after a preset period of time. The lease enables the current lease owner with exclusive use of the associated content in the memory 10 until the lease expires.

[00032] In an embodiment, the memory 10 includes a plurality of leasable memory blocks 10b. Moreover, the memory 10 may include non-leasable memory blocks 10a. In addition, a lease table 10c of the memory system 100 may be stored in the memory 10, whereas the lease table 10c includes a plurality of leases. It should be understood that the lease table can be stored in the memory access mechanism 50 or in any other location.

[00033] Each lease of the lease table 10c corresponds to a leasable memory block 10b of the memory 10. Each lease includes a plurality of lease information. The lease enables exclusive use of the content in the corresponding leasable memory block of the memory 10 by a data user. The data user can be a CPU, software, a CPU-executing process, a computer, a device, or any other component needing to write or to read content in the memory 10. Access to a leasable memory block 10b is dependent on the lease information of the lease. In addition, the non-leasable memory blocks 10a do not have a corresponding lease in the lease table 10c. For example, the non-leasable memory blocks 10a may store content that is inaccessible to a data user, may store content that does not change, or may store content that does not require exclusive use by a data user.

[00034] Importantly, the memory access mechanism 50 includes hardware components to enforce lease-based access to the content of the memory 10. In an embodiment, the memory access mechanism 50 is a memory controller 50. The memory controller 50 controls and grants access to the content of the leasable memory blocks based on the lease information in the lease table. The lease information determines whether a lease can be acquired by a data user requesting or needing exclusive use of the content of the corresponding leasable memory block for a preset period of time. Moreover, the lease information determines which data user is authorized to access the corresponding leasable memory block for a preset period of time.

[00035] In an embodiment, the lease information of each lease includes a pointer to a corresponding leasable memory block. For example, the pointer may be a buffer pointer. Moreover, the pointer may be an address+length pair. Since the address of each leasable memory block is included in the corresponding lease of the lease table 10c, an unauthorized data user cannot access the leasable memory block 10b without first securing the corresponding lease which would then provide the address or path to the leasable memory block.

[00036] In practice, a data user provides an appropriate instruction or command via connection 31 to the memory controller 50 to access the content of the memory 10. Examples of the commands include a lease_acquire command, a lease_release command, a lease_read command, a lease_write command, and a lease_inquire command. The lease_acquire command enables the data user to attempt to become the owner of a lease (“lease holder”) which corresponds to a leasable memory block so that the data user can have exclusive use of the content in the corresponding leasable memory block of the memory 10. The lease_release command enables the data user that is the owner of a lease that has not expired to release ownership of the lease so that any other data user can attempt to become owner of the lease. The lease_inquire command enables the data user to obtain lease information of a lease which corresponds to a leasable memory block so that the data user can determine the status of the lease (e.g., whether the lease has an owner, when the lease expires, etc.).

[00037] The lease_read command enables the data user that is the owner of a lease to read the content of the corresponding leasable memory block of the memory 10. In particular, the memory controller 50 verifies that the data user is authorized to read the content of the corresponding leasable memory block by using the lease information of the corresponding lease. If the data user is authorized to read the content of the corresponding leasable memory block, the memory controller 50 obtains the memory address of the corresponding leasable memory block from the lease information of the corresponding lease and supplies the memory address via the connection 33 to the memory 10. The memory 10 provides the content of the corresponding leasable memory block to the memory controller via connection 34. Moreover, the memory controller 50 provides the content of the corresponding leasable memory block to the data user via connection 32.

[00038] The lease_write command enables the data user that is the owner of a lease to write content to the corresponding leasable memory block of the memory 10. The data user supplies the content to be written to the corresponding leasable memory block of the memory 10 to the memory controller 50 via connection 32. In particular, the memory controller 50 verifies that the data user is authorized to write content to the corresponding leasable memory block by using the lease information of the corresponding lease. If the data user is authorized to write content to the corresponding leasable memory block, the memory controller 50 obtains the memory address of the corresponding leasable memory block from the lease information of the corresponding lease and supplies the memory address via the connection 33 to the memory 10. The memory controller 50 writes the content to the corresponding leasable memory block of the memory 10 via connection 34.

[00039] FIG. 2 illustrates a diagram format of a lease table 200 and a memory 10 in accordance with an embodiment of the present invention. As illustrated in FIG. 2, the lease table 200 may include a plurality of rows 261-263, whereas each row 261-263 represents a distinct lease 261-263. Each lease 261-263 of the lease table 200 corresponds to a leasable memory block 110-130 of the memory 10. Each lease 261-263 includes a plurality of lease information. The memory controller 50 sets and maintains the lease information. The lease enables exclusive use of the content in the corresponding leasable memory block of the memory 10 by a data user. The lease information may include a lease identifier 210, a lease owner identifier 220, lease expiration data 230, a lease status 240, and a pointer 250 to a corresponding leasable memory block 110-130. Since each lease is exclusive, the lease owner identifier 220 represents the identifier (e.g., CPU identification) of the data user that has exclusive use of the content of the corresponding leasable memory block of the memory 10. Ideally, the identifier should not be susceptible to manipulation by the data user. Once the lease becomes owned, other data users are prevented from acquiring it while the lease remains active, e.g., unexpired.

[00040] The lease expiration data 230 represents a preset period of time. Each lease 261-263 expires (e.g., ending authorized access) after the preset period of time elapses, allowing another data user to become the owner of the lease. The length of the preset period of time should be sufficient to allow the data user to accomplish its task, but should not be so long that error recovery is hindered. In practice, the lease expiration data 230 may be set when a data user successfully becomes the owner of a lease by using the lease_acquire command discussed earlier. Although the data user may suggest a value for the lease expiration data 230, the memory controller 50 (FIG. 1) sets the lease expiration data 230. Since the lease expires rather than being permanent, no data user is able to monopolize a lease forever. Moreover, error recovery can be expedited.

[00041] The lease status 240 may be one of the following: a leased state; an unleased state; and a lease expired state. The access privileges of a data user to a leasable memory block is dependent on the lease status 240 of the corresponding lease. If the lease status 240 is a leased state, the corresponding lease is currently owned by a data user that has an identifier that matches the lease owner identifier 220. If the lease status 240 is an unleased state, the corresponding lease is not currently owned by any data user. If the lease status 240 is a lease expired state, the corresponding lease is no longer owned (e.g., has expired) by a data user that has an identifier that matches the lease owner identifier 220 since the data user has not released the corresponding lease before the lease expiration data 230 elapses.

[00042] The pointer 250 includes a start address 253 and a length 255. As shown in FIG. 2, the lease 261 corresponds to the leasable memory block0110. The lease 262 corresponds to the leasable memory block1120. The lease 263 corresponds to the leasable memory block2130. As depicted in FIG. 2, each lease 261-263 controls an address to a corresponding leasable memory block. Since the memory controller 50 (FIG. 1) enforces the lease-based access using the lease table 200, a faulty data user is prevented from unauthorized access to content of a leasable memory block in which another data user already holds the corresponding lease. Thus, the memory controller 50 (FIG. 1) insures that no data user can perform unauthorized accesses to the memory 10, avoiding corrupting the content of the memory 10. In effect, a data user has to communicate with the memory controller 50 (FIG. 1) to get access to the memory 10, but that access is controlled by the memory controller 50 (FIG. 1) using the lease table 200.

[00043] In an embodiment, the lease table 200 is static. Upon start-up, the lease table 200 is initialized. The initialization includes setting the number of leases that correspond to the memory 10, setting the size (e.g., 2 KB, 4 KB, etc.) of the leasable memory blocks, and setting the location of the leasable memory blocks. Alternatively, the lease table 200 may be dynamic. Thus, the number of leases, the size of the leasable memory blocks, and the location of the leasable memory blocks are dynamic.

[00044] FIG. 3 illustrates a lease state diagram 300 in accordance with an embodiment of the present invention. As illustrated in FIG. 3, the lease status of a lease may be one of an unleased state 310, a leased state 320, and a lease expired state 330.

[00045] If the lease status 240 (FIG. 2) of a particular lease is an unleased state 310, any data user can perform a lease_inquire 341 command with the memory controller 50 (FIG. 1) to obtain lease information of the particular lease so that the data user can determine the status of the particular lease (e.g., whether the lease has an owner, when the lease expires, etc.). Moreover, if the lease status 240 (FIG. 2) of a particular lease is an unleased state 310, any data user can perform a lease_acquire 342 command with the memory controller 50 (FIG. 1) to become owner of the particular lease, allowing the data user exclusive use of the content of the corresponding leasable memory block. Furthermore, the memory controller 50 (FIG. 1) sets the lease status 240 to a leased state 320.

[00046] If the lease status 240 (FIG. 2) of a particular lease is a leased state 320 and the particular lease has not expired, the data user that has an identifier that matches the lease owner identifier 220 (FIG. 2) of the particular lease can perform a lease_read 343 command with the memory controller 50 (FIG. 1) to read the content of the corresponding leasable memory block, can perform a lease_write 343 command with the memory controller 50 (FIG. 1) to write the content to the corresponding leasable memory block, or can perform a lease_acquire 343 command with the memory controller 50 (FIG. 1) to extend/renew the lease expiration 230 (FIG. 2) of the particular lease. Moreover, if the lease status 240 (FIG. 2) of a particular lease is a leased state 320, any data user can perform a lease_inquire 343 command with the memory controller 50 (FIG. 1) to obtain lease information of the particular lease so that the data user can determine the status of the particular lease (e.g., whether the lease has an owner, when the lease expires, etc.).

[00047] In addition, if the lease status 240 (FIG. 2) of a particular lease is a leased state 320 and the particular lease has not expired, the data user that has an identifier that matches the lease owner identifier of the particular lease can perform a lease_release 347 command with the memory controller 50 (FIG. 1) to voluntarily relinquish ownership of the lease so that any other data user can attempt to become owner of the particular lease to have exclusive use of the content of the corresponding leasable memory block. Furthermore, the memory controller 50 (FIG. 1) sets the lease status 240 to an unleased state 310.

[00048] If the lease status 240 (FIG. 2) of a particular lease is a leased state 320 and the particular lease expires because the lease expiration data 230 (FIG. 2) elapses, the memory controller 50 (FIG. 1) sets the lease status 240 to a lease expired state 330, as indicated by the arrow 344. Thus, the current lease owner of the particular lease involuntarily loses permission to access the content of the corresponding leasable memory block. This case could be caused by an overloaded or malfunctioning data user. Thus, the memory controller 50 (FIG. 1) may initiate an error detection notification procedure to notify some component (e.g., a CPU).

[00049] If the lease status 240 (FIG. 2) of a particular lease is a lease expired state 330, any data user can perform a lease_inquire 341 command with the memory controller 50 (FIG. 1) to obtain lease information of the particular lease so that the data user can determine the status of the particular lease (e.g., whether the lease has an owner, when the lease expires, etc.). Moreover, if the lease status 240 (FIG. 2) of a particular lease is a lease expired state 330, any data user can perform a lease_acquire 346 command with the memory controller 50 (FIG. 1) to become owner of the particular lease, allowing the data user exclusive use of the content of the corresponding leasable memory block. Furthermore, the memory controller 50 (FIG. 1) sets the lease status 240 to a leased state 320.

[00050] FIG. 4 illustrates an exemplary memory controller 50 in accordance with an embodiment of the present invention. As illustrated in FIG. 4, the memory controller 50 includes a control finite state machine 51, a command register 53, a system time clock 52, a comparator 54, an address register 55, a temp register 56, and an access status register 57. The memory controller 50 controls and grants access to the content of the leasable memory blocks based on the lease information in the lease table. It should be understood that the memory controller 50 can have other configurations.

[00051] The control finite state machine 51 controls the operation of the memory controller 50. In practice, a data user provides a particular command (e.g., a lease_acquire command, a lease_release command, a lease_read command, a lease_write command, a lease_inquire command, etc.) to the memory controller 50 via connection 31. The particular command is stored in the command register 53. Depending on the particular command received from the data user, the control finite state machine 51 may initiate a number of tasks. In particular, the lease information of a particular lease may be retrieved from the memory 10 and stored in the temp register 56. The control finite state machine 51 proceeds based on the lease status stored in the temp register 56. Additionally, information from the command register 53 (e.g., data user identifier) and from the system time clock 52 may be compared in the comparator 54 with the lease information (e.g., lease owner identifier, lease expiration data) stored in the temp register 56. Moreover, the control finite state machine 51 sets the access status register 57 to an appropriate state to indicate to the data user whether the memory access was successful or unsuccessful.

[00052] FIG. 4A illustrates a flow chart 400 of steps performed for leased-based access to memory in accordance with an embodiment of the present invention. At Block 410, the lease table 200 (FIG. 2) is initialized. Initialization may include setting the number of leases that correspond to the memory 10 (FIG. 1), setting the size of the leasable memory blocks 10b (FIG. 1), and setting the location of the leasable memory blocks 10b (FIG. 1). Moreover, at Block 420, a data user acquires exclusive use of a leasable memory block by becoming owner of the corresponding lease of the lease table 200. In particular, the data user provides a lease_acquire command to the memory controller 50 (FIG. 4). If the lease_acquire command is successful, the memory controller 50 (FIG. 4) grants the data user exclusive use of the leasable memory block by making the data user the owner of the corresponding lease.

[00053] Furthermore, at Block 430, the data user uses the leasable memory block. The data user provides the lease_read command to the memory controller 50 (FIG. 4) to read the content of the leasable memory block. After verifying the data user's access privileges in the lease information of the corresponding lease, the memory controller 50 (FIG. 4) retrieves the content of the leasable memory block. The data user provides content (for writing to the leasable memory block) and the lease_write command to the memory controller 50 (FIG. 4) so that to write the content to the leasable memory block. After verifying the data user's access privileges in the lease information of the corresponding lease, the memory controller 50 (FIG. 4) writes the content to the leasable memory block.

[00054] At Block 440, the data user may voluntarily relinquish the lease of the leasable memory block. The data user provides the lease_release command to the memory controller 50 (FIG. 4) to voluntarily relinquish the lease. If the data user does voluntarily relinquish the release, any other data user may acquire the lease, at Block 420.

[00055] Moreover, at Block 450, the memory controller 50 (FIG. 4) determines whether the lease has expired. If the lease is expired, the memory controller 50 (FIG. 4) updates the lease information of the lease to reflect the lease expired state. Then, the data user involuntarily loses access privileges to the leasable memory block. Hence, any other data user may acquire the lease, at Block 420. Otherwise, if the lease is not expired, the data user retains its access privileges to the leasable memory block, at Block 430.

[00056] FIG. 5 illustrates a flow chart 500 of steps performed for a lease_acquire command in accordance with an embodiment of the present invention. At Block 510, the memory controller 50 (FIG. 4) receives a lease_acquire command from a data user. The data user indicates the particular leasable memory block whose corresponding lease the data user wants to own (or acquire). Alternatively, the data user may provide the lease identifier 210 (FIG. 2) corresponding to lease of the particular leasable memory block. The memory controller 50 (FIG. 4) retrieves the lease information (e.g., a lease identifier 210 (FIG. 2), a lease owner identifier 220 (FIG. 2), lease expiration data 230 (FIG. 2), a lease status 240 (FIG. 2), a pointer 250 (FIG. 2)) of the lease corresponding to the particular leasable memory block.

[00057] At Block 520, the memory controller 50 (FIG. 4) determines whether the lease status 240 (FIG. 2) is an unleased state or a lease expired state. The unleased state indicates that the lease of the particular leasable memory block is not currently owned by any other data user. The lease expired state indicates that the current owner of the lease of the particular leasable memory block has lost permission to access the particular memory block. If the lease status 240 (FIG. 2) is not an unleased state or a lease expired state, at Block 530 the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access denied state to indicate to the data user that access to the particular leasable memory block was unsuccessful.

[00058] If the lease status 240 (FIG. 2) is an unleased state or a lease expired state, at Block 540 the memory controller 50 (FIG. 4) sets the lease status, the lease owner identifier, and the lease expiration data of the lease of the particular leasable memory block. Moreover, the memory controller 50 (FIG. 4) stores the updated lease information in the lease table. At Block 550, the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access ok state to indicate to the data user that access to the particular leasable memory block was successful. At Block 560, the memory controller 50 (FIG. 4) sends the information of the access status register 57 (FIG. 4) to the data user.

[00059] FIG. 6 illustrates a flow chart 600 of steps performed for a lease_release command in accordance with an embodiment of the present invention. At Block 610, the memory controller 50 (FIG. 4) receives a lease_release command from a data user. The data user indicates the particular leasable memory block whose corresponding lease the data user wants to relinquish (or release). Alternatively, the data user may provide the lease identifier 210 (FIG. 2) corresponding to lease of the particular leasable memory block. The memory controller 50 (FIG. 4) retrieves the lease information (e.g., a lease identifier 210 (FIG. 2), a lease owner identifier 220 (FIG. 2), lease expiration data 230 (FIG. 2), a lease status 240 (FIG. 2), a pointer 250 (FIG. 2)) of the lease corresponding to the particular leasable memory block.

[00060] At Block 620, the memory controller 50 (FIG. 4) determines whether the lease status 240 (FIG. 2) is a leased state, whether the lease owner identifier matches the identifier of the data user, and whether the lease has expired (i.e., the lease expiration data has elapsed). If the lease status 240 (FIG. 2) is not a leased state, the identifier match is unsuccessful, or the lease has expired, at Block 630 the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access denied state to indicate to the data user that access to the particular leasable memory block was unsuccessful.

[00061] If the lease status 240 (FIG. 2) is a leased state, the identifier match is successful, and the lease has not expired, at Block 640 the memory controller 50 (FIG. 4) resets the lease status, the lease owner identifier, and the lease expiration data of the lease of the particular leasable memory block. Moreover, the memory controller 50 (FIG. 4) stores the updated lease information in the lease table. At Block 650, the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access ok state to indicate to the data user that access to the particular leasable memory block was successful. At Block 660, the memory controller 50 (FIG. 4) sends the information of the access status register 57 (FIG. 4) to the data user.

[00062] FIG. 7 illustrates a flow chart 700 of steps performed for a lease_read command in accordance with an embodiment of the present invention. At Block 710, the memory controller 50 (FIG. 4) receives a lease_read command from a data user. The data user indicates the particular leasable memory block whose corresponding content the data user wants to read. Alternatively, the data user may provide the lease identifier 210 (FIG. 2) corresponding to lease of the particular leasable memory block. The memory controller 50 (FIG. 4) retrieves the lease information (e.g., a lease identifier 210 (FIG. 2), a lease owner identifier 220 (FIG. 2), lease expiration data 230 (FIG. 2), a lease status 240 (FIG. 2), a pointer 250 (FIG. 2)) of the lease corresponding to the particular leasable memory block.

[00063] At Block 720, the memory controller 50 (FIG. 4) determines whether the lease status 240 (FIG. 2) is a leased state, whether the lease owner identifier matches the identifier of the data user, and whether the lease has expired (e.g., the lease expiration data has elapsed). If the lease status 240 (FIG. 2) is not a leased state, the identifier match is unsuccessful, or the lease has expired, at Block 730 the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access denied state to indicate to the data user that access to the particular leasable memory block was unsuccessful.

[00064] If the lease status 240 (FIG. 2) is a leased state, the identifier match is successful, and the lease has not expired, at Block 740 the memory controller 50 (FIG. 4) reads the content of the particular leasable memory block. At Block 750, the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access ok state to indicate to the data user that access to the particular leasable memory block was successful. At Block 760, the memory controller 50 (FIG. 4) sends the information of the access status register 57 (FIG. 4) to the data user. Moreover, the memory controller 50 (FIG. 4) sends the content of the particular leasable memory block to the data user if the access to the particular leasable memory block was successful.

[00065] FIG. 8 illustrates a flow chart of steps involved for a lease_write command in accordance with an embodiment of the present invention. At Block 810, the memory controller 50 (FIG. 4) receives a lease_write command and content (to be written) from a data user. The data user indicates the particular leasable memory block where the data user wants to write content. Alternatively, the data user may provide the lease identifier 210 (FIG. 2) corresponding to lease of the particular leasable memory block. The memory controller 50 (FIG. 4) retrieves the lease information (e.g., a lease identifier 210 (FIG. 2), a lease owner identifier 220 (FIG. 2), lease expiration data 230 (FIG. 2), a lease status 240 (FIG. 2), a pointer 250 (FIG. 2)) of the lease corresponding to the particular leasable memory block.

[00066] At Block 820, the memory controller 50 (FIG. 4) determines whether the lease status 240 (FIG. 2) is a leased state, whether the lease owner identifier matches the identifier of the data user, and whether the lease has expired (i.e., the lease expiration data has elapsed). If the lease status 240 (FIG. 2) is not a leased state, the identifier match is unsuccessful, or the lease has expired, at Block 730 the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access denied state to indicate to the data user that access to the particular leasable memory block was unsuccessful.

[00067] If the lease status 240 (FIG. 2) is a leased state, the identifier match is successful, and the lease has not expired, at Block 840 the memory controller 50 (FIG. 4) writes content (provided by the data user) to the particular leasable memory block. At Block 850, the memory controller 50 (FIG. 4) sets the access status register 57 (FIG. 4) to an access ok state to indicate to the data user that access to the particular leasable memory block was successful. At Block 860, the memory controller 50 (FIG. 4) sends the information of the access status register 57 (FIG. 4) to the data user.

[00068] FIG. 9 illustrates a flow chart 900 of steps performed in the case of an expired lease in accordance with an embodiment of the present invention. At Block 910, the memory controller 50 (FIG. 4) has determined that the lease expiration data of a lease has elapsed. The memory controller 50 (FIG. 4) may use a polling method, an access-initiated method, or any other method to determine whether the lease expiration data of a lease has elapsed. Moreover, at Block 920, the memory controller 50 (FIG. 4) sets the lease status of the lease to a lease expired state. In addition, the memory controller 50 (FIG. 4) stores the updated lease information in the lease table. At Block 930, the memory controller 50 (FIG. 4) optionally notifies a component (e.g., a CPU) that a data user has involuntarily lost permission to access the content of the corresponding leasable memory block, possibly indicating the existence of an error or fault.

[00069] FIG. 10 illustrates a flow chart 1000 of steps performed for a lease_inquire command in accordance with an embodiment of the present invention. At Block 1010, the memory controller 50 (FIG. 4) receives a lease_inquire command from a data user. The data user indicates the particular leasable memory block whose corresponding lease the data user desires to investigate. Alternatively, the data user may provide the lease identifier 210 (FIG. 2) corresponding to the lease of the particular leasable memory block. At Block 1020, the memory controller 50 (FIG. 4) retrieves the lease information (e.g., a lease identifier 210 (FIG. 2), a lease owner identifier 220 (FIG. 2), lease expiration data 230 (FIG. 2), a lease status 240 (FIG. 2)) of the lease corresponding to the particular leasable memory block. Moreover, at Block 1030, the memory controller 50 (FIG. 4) sends the lease owner identifier, lease expiration data, and the lease status of the lease to the data user.

[00070] The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.