5.) Storage Hierarchy

To clarify the "guarantees" provided at different settings of the persistence spectrum without binding the application to a specific environment or set of storage devices, MBFS implements the continuum, in part, with a logical storage hierarchy. The hierarchy is defined by N levels:

1.LM (Local Memory storage): very high-speed volatile storage located on the machine creating the file.

2.LCM (Loosely Coupled Memory storage): high-speed volatile storage consisting of the idle memory space available across the system.

3.-N DA (Distributed Archival storage): slower speed stable storage space located across the system.

Caching

Caching is a well known concept in computer science: when programs continually access the same set of instructions, a massive performance benefit can be realized by storing those instructions in RAM. This prevents the program from having to access the disk thousands or even millions of times during execution by quickly retrieving them from RAM. Caching on the web is similar in that it avoids a roundtrip to the origin web server each time a resource is requested and instead retrieves the file from a local computer's browser cache or a proxy cache closer to the user.

The most commonly encountered caches on the web are the ones found in a user's web browser such as Internet Explorer, Mozilla and Netscape. When a web page, image, or JavaScript file is requested through the browser each one of these resources may be accompanied by HTTP header directives that tell the browser how long the object can be considered fresh, that is for how long the resource can be retrieved directly from the browser cache as opposed to from the origin or proxy server. Since the browser represents the cache closest to the end user it offers the maximum performance benefit whenever content can be stored there.

Coherency and Consistency

Consistency

Instead of attempting to impose some sort of ordering rules between individual memory reference instructions, as with most consistency models, TCC just imposes a sequential ordering between transaction commits. This can drastically reduce the number of latency-sensitive arbitration and synchronization events required by low-level protocols in a typical multiprocessor system. As far as the global memory state and software is concerned, all memory references from a processor that commits earlier happened “before” all memory references from a processor that commits afterwards, even if the references actually executed in an interleaved fashion. A processor that reads data that is subsequently updated by another processorʼs commit, before it can commit itself, is forced to violate and rollback in order to enforce this model. Interleaving between processorsʼ memory references is only allowed at transaction boundaries, greatly simplifying the process of writing programs that make fine-grained access to shared variables. In fact, by imposing an original sequential programʼs original transaction order on the transaction com-mits, we can effectively let the TCC system provide an illusion of uniprocessor execution to the sequence of memory refer-ences generated by parallel software.

Coherency

Stores are buffered and kept within the processor node for the duration of the transaction in order to maintain the atomicity of the transaction. No conventional, MESI-style cache protocols are used to maintain lines in “shared” or “ex-clusive” states at any point in the system, so it is legal for many processor nodes to hold the same line simultaneously in either an unmodified or speculatively modified form. At the end of ••Figure 1: A sample 3-node TCC system.Local Cache HierarchyProcessor CoreStoresOnlyLoads andStoresCommitsto other nodesWriteBufferData Tag V M Read Re-nameSnoopingfrom other nodesCommit ControlPhase SequenceNode 0:Node 1:Node 2:Broadcast Bus or NetworkNode#0each transaction, the broadcast notifies all other processors about what state has changed during the completing transac-tion. During this process, they perform conventional invalida-tion (if the commit packet only contains addresses) or update (if it contains addresses and data) to keep their cache state coherent. Simultaneously, they must determine if they may have used shared data too early. If they have read any data modified by the committing transaction during their currently executing transaction, they are forced to restart and reload the correct data. This hardware mechanism protects against true data dependencies automatically, without requiring program-mers to insert locks or related constructs. At the same time, data antidependencies are handled simply by the fact that later processors will eventually get their own turn to flush out data to memory. Until that point, their “later” results are not seen by transactions that commit earlier (avoiding WAR dependen-cies) and they are able to freely overwrite previously modified data in a clearly sequenced manner (handling WAW dependen-cies in a legal way). Effectively, the simple, sequentialized consistence model allows the coherence model to be greatly simplified, as well.