System for maintaining data coherency in cache memory by periodically broadcasting invalidation reports from server to client

Description Submit all comments and votes

FIELD OF THE INVENTION

The present invention relates generally to the field of cache memories, and in particular to cache memory management strategies for distributed computing environments.

BACKGROUND OF THE INVENTION

A cache memory is a memory that is packaged as an integral component of a processing unit in a computer system. The cache is generally much smaller than main memory. Its purpose is to serve as a buffer between the processors and the memory, emulating the main memory, but with a much faster access time.

For multiprocessor systems, the cache management strategy also includes algorithms that provide a coherent view of storage to all of the processors in the system. Coherency implies that store operations to a memory location performed by a given processor (e.g., a server) will be made consistent with fetch operations done to the same memory location by another processor (e.g., a client). Coherency provides a means for determining when cached data in a given processor becomes obsolete as a result of store operations performed by another processor.

In the Andrew file system, for example, the server maintains a record of which data is cached in each of the clients. Typically, coherency is maintained by providing a valid bit for each datum in each respective client's cache. A "cross invalidate" (XI) is the act of invalidating, or marking non-resident, a line in the cache of a remote processor. When a server needs to change the value of a datum, the server broadcasts XI messages to all of the other processors that may have a copy of the same datum in cache. If a copy of the datum is present in one of these other caches, that copy is marked invalid (e.g., the valid bit is reset) in response to the XI. Only after all copies are marked invalid does the first processor change the target data value. A request for the datum then results in a cache miss.

In the Network File System, the server does not have to keep track of which clients have copies of each respective datum. Whenever a client needs to access data in its respective cache, it queries the server to verify that its copy of the data is current.

The paradigms described above work well when all of the processors in the system are active at the same time, and when the communications paths between the processors are static. Typically, this has been the case when all of the processors are collocated and are operated continuously.

The introduction of wireless cellular communications and palmtop computers into the marketplace introduces new capabilities and also poses new technical challenges. The need to share data in this distributed and mobile environment presents one of these challenges. It is desirable to share data among fixed location mobile unit support stations and mobile palmtop units.

The conditions in a mobile wireless computing environment differ from those encountered in the static, collocated multiprocessor systems described above. In the mobile environment, a large number of users equipped with low powered palmtop machines may query databases over wireless communications channels. Palmtop units are often powered down (taken off-line) for prolonged periods of time to conserve battery energy. Thus, if palmtops are equipped with caches, the palmtops may not always be available to receive cross invalidate messages from the mobile unit support stations, if such messages are sent.

Furthermore, the palmtop users do not maintain fixed or universally known positions in the wireless network. A given palmtop unit may be in communication with different mobile unit support stations at different times. The mobile unit support stations cannot predict which palmtop units will be within their respective radio coverage areas at any given time.

Although the mobile unit support stations may be located in proximity to one another, for example, within a single building or campus, it is contemplated that palmtop machines will also communicate over conventional cellular communications networks as well. In the latter case, the communications bandwidth may be limited (e.g., 10 to 20 kilobits per second). The bandwidth places a limit on the number of queries to which the server can respond in a given period of time. Because of the limited bandwidth in the cellular environment, it is impractical for each palmtop to query the mobile unit support station for a complete database refresh each time the palmtop user wishes to access data after returning to the on-line state. The mobility of the palmtops, their frequent unavailability to receive XI messages, and communications bandwidth limitations make caching of data within the palmtops by the conventional paradigms difficult.

The above identified factors tend to make communications with palmtop machines more complex. At the same time, some of the constraints that have driven the design of many prior art systems may not apply in some of the applications for palmtop computers. For example, palmtops may be used by consumers to access data that are updated with a frequency that is much smaller than the frequency of queries sent from the clients to the server. Additionally, some palmtop applications may tolerate a small, known probability that the data in the palmtop are considered to be current when in fact the data have been updated (For example, when updates are infrequent and are minor). For such applications, the prior art cache management strategies for distributed systems may be inefficient.

An improved method for maintaining a coherent view of the data in the cache of each mobile unit is desired. Desirably, the improved method would not require the mobile units to stay on-line at all times, and would not require a full cache refresh each time a mobile unit is turned on.

SUMMARY OF THE INVENTION

The invention is a method and system for maintaining coherency between a server processor and a client processor that has a cache memory. The server stores a plurality of data values, and the client stores a subset of the plurality of data values in the cache.

The server processor periodically broadcasts invalidation reports to the client processor. Each respective invalidation report includes information identifying which, if any, of the plurality of data values have been updated within a predetermined period of time before the server processor broadcasts the respective invalidation report.

The client processor determines, based on the invalidation reports, whether a selected data value in the cache memory of the client processor has been updated in the server processor since the selected data value was stored in the cache memory. The client processor invalidates the selected data value in the cache memory of the client processor, if the selected data value has been updated in the server processor.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram of an exemplary system in accordance with the invention.

FIG. 2 is a flow chart diagram of a method for maintaining cache coherency in the system of FIG. 1.

FIG. 3A is a detailed flow chart diagram of an exemplary method for forming and broadcasting invalidation reports as shown in FIG. 1.

FIG. 3B is a flow chart diagram of an exemplary method for processing the invalidation reports produced by the method shown in FIG. 3A.

FIG. 4A is a detailed flow chart diagram of a second exemplary method for forming and broadcasting invalidation reports as shown in FIG. 1.

FIG. 4B is a flow chart diagram of an exemplary method for processing the invalidation reports produced by the method shown in FIG. 4A.

FIG. 5A is a detailed flow chart diagram of a third exemplary method for forming and broadcasting invalidation reports as shown in FIG. 1.

FIG. 5B is a flow chart diagram of an exemplary method for processing the invalidation reports produced by the method shown in FIG. 5A.

DETAILED DESCRIPTION

OVERVIEW

FIG. 1 is a block diagram of an exemplary system in accordance with the invention, for maintaining coherency between data stored in one or more server processors 10a-10d and one or more client processors 20a-20f. The invention may be used advantageously in an environment in which the clients are taken off-line part of the time and are not available to receive invalidation messages at all times. The invention also may be used advantageously in environments in which the frequency of data updates by the server 10a-10d is much less than the frequency of queries by the clients 20a-20f.

Each server 10a-10d stores a plurality of data values. The servers 10a-10d all have access to a common body of data. The servers 10a-10d may, for example, include databases covering a variety of subjects, such as financial data, news, weather, documents, etc. Such data may be accessed by palmtop computers 20a-20f over a cellular network.

The servers 10a-10d are coupled via communications links to one or more client processors 20a-20f. Each of the clients 20a-20f has a respective cache memory 22 for storing a subset of the of the data that are stored in the servers 10a-10d. For simplicity, only one cache memory 22 in client 20a is shown in FIG. 1. The cache memories (not shown) in the remaining clients 20b-20f may be identical to cache 22. Any of the clients 20a-20f may store copies of any subset of the data in its respective cache 22. Therefore the contents of the caches 22 may differ.

In the exemplary embodiment, the servers 10a-10d are connected to each other by a fixed (i.e., stationary) network 18 and the couplings between the servers 10a-10d and the clients 20a-20f are wireless. The exemplary clients 20a-20f are mobile units (MU), such as palmtop computers. The exemplary servers 10a-10d are mobile unit support stations (MSS). Each MSS 10a-10d communicates within a respective radio coverage area called a cell 12a-12d. An MU 20a-20f may move between any of the cells 12a-12d.

FIG. 2 is a flow chart diagram showing an exemplary process according to the invention.

Each server 10a-10d includes a process for forming and broadcasting periodic invalidation reports to any of the clients 20a-20f currently located within its respective cell 12a-12d. At step 100, the server begins to periodically form and broadcast invalidation reports. Each invalidation report includes information identifying which of the data values stored in the server 10a-10d have been updated within a predetermined interval of time (hereinafter referred to as a window), before the server 10a-10d broadcasts that invalidation report. The period of the broadcasts may be the same as, or different from, the length of the window. For example, the window may be six to ten times as long as the period. The servers 10a-10d broadcast the reports over a wireless medium (e.g., radio frequency). The servers 10a-10d need not maintain records of which clients are located in each respective cell 12a-12d, or of the contents of the respective cache 22 of each client 20a-20f.

At step 104, each client 20a-20f receives the invalidation reports if the client is turned on and is in an on-line state. At step 106, based on the invalidation reports, each client 20a-20f determines whether any of the data in its respective cache memory 22 are copies of data that have been updated in the server 10a-10d since the time that the copies were stored in the cache 22. If so, then the copies of the data in the cache 22 are invalid. At step 106, the clients 20a-20f determine which data have been updated in the servers 10a-10d. Then at step 108, the clients 20a-20f mark these data invalid in the cache 22. At step 110, the clients 20a-20f query the respective servers 10a-10d for any requested data that are not present in cache 22.

According to an advantageous aspect of the invention, the clients 20a-20f may be taken off-line at any time. For example, if clients 20a-20f are palmtop computers, the clients 20a-20f may be carried around by the operators from one location to another (and perhaps from one cell 12a-12d to another). The palmtop computers may not always be needed. When a palmtop computer is not needed (step 112), it may be taken off-line at step 114 to conserve battery power.

At steps 116-120, the clients 20a-20f may update their caches in response to the invalidation reports received after returning to an on-line state, even though the clients 20a-20f miss some of the invalidation reports when the clients 20a-20f are off-line. The invalidation reports contain "cumulative" information sufficient to enable the clients 20a-20f to determine all data that have been invalidated during the window time. This may be accomplished so long as the off-line time does not exceed the window time at step 120. If the off-line time does exceed the window time at step 120, then all items in the cache are invalidated at step 122.

If the invalidation report does not indicate that a datum is invalid, and the client has not been off-line for a time greater than the window, then the data in the client's cache 22 are presumed by the client to be valid as of the time the invalidation report is broadcast. Note that some latency is introduced into the query process when the clients 20a-20f wait for the report. In between reports, a datum may be updated in the server 10a-10d; the clients 20a-20f are not notified until the next report is broadcast. Thus the period between validation reports is selected to be small enough, relative to the update frequency, so that the risk of using "stale" data in between reports is reduced to an acceptable level.

The method shown in FIG. 2. may reduce the number of queries that each client 20a-20f must make to refresh its cache after a request for data. By reducing the number of queries, the traffic loading between the servers 10a-10d and the clients 20a-20f is reduced, and it is possible to serve a greater number of clients 20a-20f, or handle a larger database in the server 10a-10d.

According to another aspect of the invention, the clients 20a-20f accept invalidation reports from any of the servers 10a-10d when the clients are located within the respective cells 12a-12d of those servers 10a10d. Upon return to an on-line state, the client 20a-20f accepts the next invalidation report broadcast by the nearest server 10a-10d, determines which data in the cache 22 are invalid based on the invalidation report, and invalidates any of the data in the cache 22 that the client 20a-20f determines to be invalid.

Another exemplary application for the invention is in a retail store, such as a supermarket. Consumers may carry portable devices throughout the store. These portable devices may be equipped with scanners (e.g., optical or magnetic scanners) for reading product labels. The devices scan the product labels, query the server for the prices, and store the prices in cache. The consumers may use the stored prices to compute the total cost of an order of goods. This is an example of a query intensive environment, in which the server may only update a given price once per day or once per week, but the clients query the server many times per hour.

THE EXEMPLARY EMBODIMENTS

The invention may be implemented in many different ways, including but not limited to the exemplary embodiments, described below. The contents and frequency of the invalidation reports, and the response of the client processors upon receipt of the reports is selected based on the nature of the environment. The goal of selecting a particular strategy is to limit the number of queries from the client processors in a given time interval to a number less than the maximum number of queries that may be satisfied by the server in that interval. Specific factors that may be considered in defining the strategy include the frequency of updates to the data, the frequency of queries, and the fractional time that each client is in the on-line state.

One extreme end of the spectrum is the environment in which updates are very frequent relative to queries. In such a situation, the cache hit ratio is expected to be very low, regardless of which method for maintaining cache coherency. In such an environment, the use of a cache in each client may not be efficient. That is, performance may be much the same regardless of whether a cache is included in the client configuration. The invention is most effective at the other end of the spectrum (when updates are infrequent and requests for data are frequent, so that the cache hit ratio is high).

Three alternative strategies for defining the contents of the invalidation reports are described below. Each of the strategies may provide better system performance (defined by the number of queries to which the server 10a a can respond per unit of time) in a respectively different environment. For each respective strategy described below, the environment in which that strategy may be preferred is described.

The inventors have determined that the first exemplary embodiment provides the greatest throughput when the client processors 20a-20f are on-line all, or nearly all of the time (In other words, if the time on-line is several times greater than the time off-line). This exemplary embodiment is referred to herein as "Broadcasting Addresses" and is shown in FIGS. 3A and 3B. In this embodiment, the servers 10a-10d store a list of the addresses of each respective datum that has been updated since the last invalidation report was broadcast. The clients 20a-20f invalidate the items on the list. A client 20a invalidates every datum in its cache 22 if it has missed one or more reports, as explained in detail below.

FIG. 3A is a flow chart diagram of the process executed by the server 10a to create and broadcast the invalidation reports. At step 200, the list of updated data is cleared. At steps 201 and 202, each of the data in the server 10a that is shared with the clients 20a-20f is checked to determine whether the datum has been updated since the last invalidation report. At step 204, if an item has been updated, the address of that datum is added to the list. At step 206, after each datum is checked, the report is broadcast to the clients. The report only includes the list of addresses. This method results in a very short invalidation report. This minimizes the fraction of the available bandwidth used for transmitting invalidation reports, and allows the server to broadcast responses to more queries.

FIG. 3B is a flow chart diagram of the process executed by the client 20a when it receives the invalidation report created by the process shown in FIG. 3A. At step 210, the process begins when the client is on-line, either continuously or after a period of off-line status. At step 212, the client 20a receives the next invalidation report broadcast from the server 10a. Then, at step 214, the client determines whether any reports have been missed, based on the time that the last report was received by the client. The period of the reports is a predetermined time interval that is known to the clients (Alternatively, the period of the reports or the time of the last prior report may be included as an item in the report). Thus, the client 20a can determine whether any reports were sent from the server 10a and not received by the client 20a.

In the first exemplary embodiment of the invention, if the client determines that one or more reports have been missed at step 214, then every entry in the cache 22 is invalidated at step 226. Steps 216 to 220 are repeated for each valid datum in the cache, if the client has not missed any reports at step 214. At step 218, for each datum in the cache 22, the invalidation report is checked to determine whether the address of that datum is in the report. If the address of the datum is in the report at step 218, then the datum is marked invalid at step 220. The items remaining in cache after steps 216 to 220 are executed are presumed to be valid. At step 222, when the report has been processed, the client 20a queries the server for the current value of any datum that is needed and not resident in cache. At step 224, when the client's work is completed, the client 20a may be powered down to the off-line state.

The invalidation reports produced by Broadcasting Addresses (as shown in FIGS. 3A and 3B) do not include any timestamp information for the individual items listed in the report. In between reports, clients 20a-20f that have been continuously on-line assume that any data in cache that are not listed in the most recently received report are still valid. If any addresses are listed in a report, the clients 20a-20f assume that the data stored at the addresses listed were all updated immediately after the last previous report. This may cause a client 20a to misdiagnose a datum as invalid, increasing the query rate.

For example, consider the case in which the following events occur in order: (1) a server 10a broadcasts a report at time TO and updates a datum at time T1; (2) the client 20a returns to an on-line state and queries the server for the same datum at time T2; and (3) the server responds to the query at time T3 and issues the next invalidation report at time T4. Even though the client 20a receives the updated value of the datum at T3, upon receipt of the invalidation report at T4, the client assumes that the datum was updated immediately before T4. The client incorrectly diagnoses the copy of the datum received at T3 as invalid.

The situation described above seldom occurs when the clients 20a-20f are on-line nearly all of the time. Furthermore, the first exemplary method, Broadcasting Addresses, has the advantage that the invalidation report may be relatively small, because it only requires an address for each datum. Thus, Broadcasting Addresses may be preferable for continuous and near-continuous client operation.

The inventors have determined that the throughput for the first exemplary method, in terms of queries responded to by the server per unit of time, may be approximated by equations (1) and (2). ##EQU1## where: T=Throughput in responses per second

L=Period between invalidation reports

W=Bandwidth of server--client link

c=Expected number of updates per period equals n(1-e.sup.-.mu.L)

b.sub.c =Bytes added to report per updated datum, equal to log(n)

n=number of data in server

b.sub.q =Bytes per query

b.sub.a =Bytes per answer to query

h.sub.at =Hit ratio

.lambda.=queries per second

q.sub.o =probability of being on line and having no queries in an interval of length L,

where

q.sub.o =(1-s)e.sup.-.lambda.L

s=probability of being disconnected during an interval of length L

p.sub.o =probability of no queries during an interval of length L=s+q.sub.o

u.sub.o =probability of no updates during an interval of length L=e.sup.-.mu.L

.mu.=changes per datum per second

The inventors have determined that the second exemplary embodiment, hereinafter referred to as "Broadcasting Timestamps" may provide better throughput for query intensive environments in which queries are several (e.g., seven or more) orders of magnitude more frequent than updates, and the client processors 20a-20f are on-line a substantial fraction of the time (but not substantially all of the time). This exemplary embodiment is shown in FIGS. 4A and 4B. In this embodiment, both the servers 10a-10d a