A Multiconsistency Memory Protocol Test Environment on Chorus

Abstract

this paper, we describe the structure of our experimental test environment built on top of the Chorus micro-kernel. The results of our study will be the basis of a distributed shared virtual memory subsystem. We also provide centralised synchronization services, enhanced mechanisms will be studied in future works. Fault tolerance constraints have not been considered in our design. Section 2 of this paper recalls the Chorus memory abstractions used to build our environment. Section 3 describes the multiconsistency test environment. Section 4 concludes with future works. 2. The Chorus Memory Model Chorus extends the basic memory abstractions (actors, segments, regions and local caches) [Ortega93] [Chorus94b] to support distribution and implementation of application personalities: . subsystem : A subsystem is a collection of actors and libraries that exports a given system interface to users. This interface offers a well defined memory model. It hides the underlying distribution of data. The subsystem has its own memory consistency semantic. . mapper : A mapper is a system actor dedicated to data management. Mappers serve kernel page requests. These requests are mainly page faults and page flushes, they concern segments local caches. We refine this definition. - segment mapper : A segment mapper, also called real mapper, serves kernel data requests to disk repository. It can provide other facilities as naming or access control management. - memory consistency mapper : Segments can be mapped on more than one site. Consequently, the coherency of different copies of a same segment has to be maintained following the subsystem consistency policy. Memory consistency is handled at cache level. A protocol between memory mappers guarantees the required memory consistency semantic. ..