DE10246369A1 - Regulating data access to data of at least one data memory involves individual systems reserving data or address areas of data source, blocking against access by other individual systems with locks with local and temporal components - Google Patents

Abstract

The method involves individual systems reserving data or address areas of a data source and blocking the individual areas against access by other individual systems, whereby the reservations or locks have local and temporal components. Address regions and/or partial address regions are shifted so that the allocation of logical addresses to physical addresses is altered in accordance with the shift operation while maintaining the physical addresses.

Description

1 goals and basic idea

The new operating system architecture intended a complete merger of databases and enable operating systems as well as the functionality of distributed operating systems, network operating systems and real-time operating systems, with or without MMU hardware, all on one enable common code base.

Of the key this is a universal extensibility and dynamic configuration at runtime, making the new architecture in principle for each This application is suitable. In addition, new application areas can be tapped by configurations that are neither with previous ones Operating systems even with databases easily feasible were.

Reached This goal is through the abstractions nest and building block. It will demonstrated that a performant operating system is essentially can be built solely from these two abstractions.

Opposite current ones Operating system and core architectures reduce internal complexity in many cases, because a relatively small amount of primitive basic operations are very wide areas of the essential basic functions of an operating system covers; not just concepts like inodes and their caches are going through replaced the concepts nest and building block, but even so far absolutely necessary concepts such as file systems as such.

The architecture presented does not write any special implementation paradigms in front; there are both implementations through server processes ("Communicating Sequential Frocesses ", e.g. in microkernel architectures) as well as implementations by Role change of user processes in core modes, as well as in mixed forms possible for these paradigms.

1.1 Introduction

The The basic idea of this work is to have an operating system at all To build layers and layers essentially from two abstractions: Nests and building blocks.

More precise definitions follow later; for understanding this introduction It is enough to have a nest instance as a (virtual) address space imagine where data can be located. Not all places this Address space must be accessible, it can any holes be present in it. This is similar a sparse file under Unix, only with the difference that requests on holes be treated as a mistake. In extension to previously used Address space abstractions have nests on a move operation move, with which a whole block of memory in the virtual address space can be moved in a virtual way. The memory block appears subsequently under moved virtual addresses; the implementation is done however, so that no actual Copy operations in memory expire, but only the virtual one Impression of a shift arises.

building blocks one can imagine oneself as "Transformatoren", which one or more entrance nests into one or more other exit nests transform. Blocks can be instantiated, i. you can choose any produce many incarnations of the same building block type whose inputs with the exits of others Connect or "wire" block instances as for people easy to understand Representation I use drawings, as in the electrical and Digital technology for Schematics are used. A block instance is shown as a box left-side entrances and right-sided outputs drawn. The "wiring rules" are the same as in circuit diagrams in electrical engineering.

The first example is in 1 a scenario as it occurs with conventional operating systems. At the end of the building block hierarchy is an instance of mmu_i386, which maps a (not shown) virtual user address space 1: 1 on its input nest by using the MMU hardware (Memory Management Unit). The user address space contains exactly what is "located" in the input nest of this block, or what is provided there (virtually) by the predecessor block, in this example, a virtual process image that is generated by the union instance and composes as essential basic elements in each case a code, a data, a stack "segment" and a virtual image of a mmap file to an executable process image. However, the term "segment" is not used in this work because it coincides with, or is a special case of, the nest abstraction (usually contains a segment only no holes).

Of the union block is fed from multiple sources. Three of them are Nest instances conventionally referred to as "files" or "files": a source is a device_ramdisk instance, the fleeting ones Memory (in practice it makes sense to use a buffered "temporary file" for this purpose) in case of lack of storage it is possible to outsource to background storage).

The "file" nests are again from sources bearing the name dir_ *. The you _ * - building blocks fulfill approximately the same functions as directories in conventional file systems. Unlike conventional file systems, they implement no directory trees, but only flat directories. By nesting you _ * instances can easily be conventional directory tree hierarchies replicate. One can imagine a you _ * - instance as a kind of "container", the the place for its initial nests are allocated and managed in its entrance nest. The fact is exploited that the entrance nest the relative cheap move operation provides move, with the help of which space management easily detachable becomes. Shift operations can For example, when new starting nests are added or if the size or the space requirement of an initial nest changes.

The cheap virtual move operation must come from somewhere and to be implemented; this is done by the map_simple instance, the in the example at the "root" of the directory hierarchy stands. There, those problems are solved that are conventional File systems are known as fragmentation problems (local behavior of access).

The upstream buffer instance ensures the decoupling of the temporal Access behavior to slow peripheral devices such as Hard drives (device_ide), and lets himself go from the functionality compare to conventional buffer caches.

All Represent lines in the drawing Nest instances, each with the same interface. The components are therefore in almost any way with each other combinable (the only question is which combinations make sense).

The example in 2 should demonstrate the flexibility of this system suggestively. Compared to earlier, two remote instances are added, which transfer the client-server paradigm to nests. A remote instance makes a nest available on another machine as if it were there locally. In the example, the one remote instance is at the end of the hierarchy and makes a complete process image available on another computer. There is another mmu_i386 instance in which parallel control flows can physically run on another machine. With similar configurations, for example, distributed-number-crunching or process migration can be performed.

The another remote instance represents the other extreme of possible Usage scenarios: the previous "root" of the directory hierarchy is on available on another computer made; this functionality is similar to that of conventional network file systems. As you can see from this example, no new block type needs to be implemented to become. However, the other components need to be more precise later examined competence, namely the multiuser or multi-version competence. Only if this is given, may inputs of several Block instances are connected in parallel to the same output.

The Example 3 is intended to indicate how the functionality of databases implement nest and building block based on the abstractions. The The basic idea is to (relational) database tables in nests store. The building block joins perform the well-known join operation by making a virtual one at its output Product table available which can be readable and, if necessary, modified within certain limits can be. The following transaction block serves as an isolation buffer for two transactional ones Views, the independent isolated views with the known ACID property (see, e.g. [HR83; LS87, GR93]). The two views are in the example in user address spaces displayed; so we have a synergy between the Specialization of operating systems and databases.

As you can easily imagine, transactional views are not only useful for traditional database applications, but can also be used at different locations in a building block hierarchy, for example, to isolate complete process images, or at the other extreme, from solid serve to disk partition images.

2 design principles

In like this chapter I present and explain the general principles which the presented operating system architecture is based.

2.1 Genericity: choice the appropriate level of abstraction

base all considerations is the functionality which must implement an operating system if there are specific requirements fulfill should.

The requirements are in this work as "free variable" considered ^one needs to change continuously;. Therefore, classes are considered requests informally.

For the too implementing functionality applies an informal law, which comes in the vernacular as "nothing nothing "known is. Everything the system should do (regardless of what it should be) somehow somehow be implemented by anyone.

Common methods for solving this problem are mainly taught in software engineering, especially in object-oriented design methods (eg [Mey88]) (keyword adaptability to new tasks). The object-oriented approach seeks to improve the reusability of software modules by enabling the extension of existing modules and interfaces for the purpose of adapting to new tasks. In practice, object-oriented software with a longer history of development often reveals a vast collection of classes with a rather complicated class hierarchy and difficult-to-understand inheritance and containment relationships ("is-a" and "has-a" relationships). On closer inspection, there is a lot of redundancy that (maybe) could have been avoided if the present requirements had been known from the start and taken into account with careful system design ² .

The general issue is therefore how to avoid unnecessary redundancy in the implementation as possible can largely avoid, even if all requirements (still) are not known at all.

2.1.1 Parametric Genericity

One Means to avoid unnecessary Redundancy is the use of genericity.

When genericity I look at every means that allows to write down similar things only once, though they occur several times (possibly in variants).

This definition is much more far-reaching than the use of the term genericity, which is often used in the literature (see, for example, [Mey88, Chapters 6 and 19]). I do not use this term in its pure form, but always look at varieties ³ of genericity.

A special feature is the parametric genericity. Examples therefor are replacement mechanisms, e.g. the lambda calculus (see e.g. [Fie88]) and its application in functional languages such as Lisp or ML or Haskell (see [Tho96]), parameter substitution in macro preprocessors, Parameters of template mechanisms in object-oriented languages such as C ++, or keyword applications generic in Ada. parametricity means that unlike more general substitution mechanisms such as. Chomsky type 0 grammars or L systems none arbitrary Replacements possible are syntactically uniquely identified placeholders, which are called formal parameters, by terms or expressions with a fixed syntax (current parameters).

In the literature, the naked concept of genericity is often used in roughly the same sense as parametric genericity, or, in still further limitation, synonymous with parametric polymorphism of types (see [CW85]), for example, Meyer [Mey88, Chapter 6 and 19] ⁴ . The concept of parametric genericity does not require the presence of type tests ⁵ , but ideally such mechanisms should be present. Allow modern functional languages like Haskell Type safety through automated type inference even with type parameters (parametric polymorphism of types, see [CW85]). In contrast, macro preprocessors usually only perform a pure text substitution, which is universally applicable to arbitrary programming language constructs, but does not allow separate pre-compilation and type checking of macros ⁶ .

parametric genericity allows the automation of repetitive programming and Formulation processes. Formal parameters can several times in different ways by different current parameters be substituted. This makes a compact notation possible Redundancy in the formulation of an algorithm helps to save. This Effect is not only in programming on a small scale, but also usable in programming on a large scale.

in the Below, I will introduce more types of genericity in an informal way, which can be represented and simulated by parametric genericity to let. These informally used terms do not represent an independent theoretical Concept rather than thinking categories or better thinking aids for the Design of complex systems thought by humans.

The basic rule of design is: use genericity wherever it is easily possible and wherever it can save redundancy ⁷ .

2.1.2 Expansion Genericity

The extension or specialization used in object orientation of interfaces through inheritance (occasionally the limitation of Interfaces) can be also as a special kind or as a special case of parametric genericity characterize: extension genericity.

Expansion genericity can be also by theoretical terms such as subtypes (subtyping, see [CW85]) or more practical manifestations How to describe abstract base classes.

In Appendix A, an example shows that inheritance can be simulated in principle by parametric genericity ⁸ . This example is not intended to be a model of good software engineering, but merely to show that inheritance can in principle be replicated using primitive means such as the C preprocessor, although the C preprocessor can not even evaluate conditional expressions within macro-expansions however, it would be very useful to copy overridden methods). The interested reader, who tries to understand the example in Appendix A, is referred to the artifice that in some macro languages one can also compute the names of macros to be expanded; in the C preprocessor one needs the concatenation operator ##. Among other things, this trick is often used in the circles of T _E X programmers (see \ csname in [Knu94]).

Out From a theoretical point of view these are functions of higher orders. Some proponents of object-oriented design methods such as e.g. [Mey88, Section 3.6.3] use a limited term compared to here of genericity, then they do not have the power he would be confident in the appropriate version in theory, however has. This power also includes essential basic concepts of object orientation. Therefore I look at genericity par excellence, under which the object orientation as Special case is subordinated.

2.1.3 Compositional genericity

Another particular form of genericity plays in uniform IO interfaces such as [Che87], in stackable file system layers such as [HP94] ⁹ , in the streams of System V Release 4 [GC94, Chapter 7], or in the port concept of Gnu Hurd [Hur] a role that can be regarded as a forerunner of the architecture presented here. Conceptually, the systems mentioned favor the same kind of genericity as in the architecture presented, which I would call compositional genericity. At first glance, compositional genericity does not seem to be parametric genericity, because the syntactic representation often looks different than in functional languages or macro languages. However, as we will see in Section 6.3, building blocks implement functions in a broader sense, with the wiring of building blocks to more complex networks considered to be a special way of composing functions. Compositional genericity is also a variant of parametric genericity, which, however, differs greatly from extension genericity in the design philosophy (but not necessarily in the mechanisms used): while object-oriented paradigms and popular hierarchy concepts in the 1970s [ Dij68, Dij71, BS75] expressly the extension of interfaces or of abstract machines aiming at new functionality by adding further operations and abstractions, the opposite is aimed at in terms of compositional genericity: the basic features of the interface must remain the same or at least largely compatible on all or as many hierarchical levels as possible in order to allow a wide variety of combinations. With compositional genericity, the enhancement of functionality is not achieved by extending the interfaces, but by adding further functionality within the combined functions; new functionality results from the special way of wiring to a network.

2.1.4 Universal Genericity

In order to be able to extend compositional genericity beyond the previous field of application of IO interfaces [Che87] to the entire operating system, not only the image and image areas of the functions involved must fit together, but they must also enable another type of genericity, the I want to call universal genericity ¹⁰ . Examples of universal constructs are Turing machines or register machines, which in principle can simulate other Turing or register machines. Universal Genericity is analogous to the ability to alternate functions, representations, access performance, granularity, etc. to simulate ¹¹ with relative ease; the term is therefore not an absolute concept, but always applies only relative to the universe of each simulated alternative concepts.

One example for universal genericity in operating systems is the well-known File IO interface of Unix [RT74], because of their ability to IO with any dynamic block length and any access patterns also older ones File concepts such as Simulate punch card stacks with fixed record length can, about it but also different access patterns of different readers and scribe allows with the usual ones Set-oriented IO interfaces can not be realized in a simple way were. This historical now taken for granted Example of a simplification by universal genericity shows on that "less often more "is: the Renouncement of the concept of a record in Unix not just the interfaces and the implementation easier, but improve it In addition, even the functionality. Universal Genericity is therefore to a great extent is desirable and especially in the design of the nest abstraction (Chapter 3) play a prominent role.

2.1.5 Application questions of genericity

• • Wie sollen die Bild- und Urbildbereiche aussehen?
• • Welche Funktionalitäten sollen durch die Bausteine realisiert werden?

The central questions in the application of compositional and universal genericity are:

• • What should the image and image areas look like?
• • Which functionalities should be realized by the blocks?

this Asking questions is the common problem of choosing the most appropriate one Abstraction level for the ones to be solved Tasks (for partially unknown requirements). The Presentation and propagation of a particular mechanism alone not much about their concrete application in a particular area. Design Decisions are not always clear due to proven methods and insights solvable since the consideration of the problem is already a human one Interpretation process is. In this work I will therefore the Pragmatics give a comparatively large space and syntactic and semantic constructs only for clarification and notation of the use underlying ideas.

A concrete choice of levels of abstraction could justify the legitimate criticism that precise statements about the advantages and disadvantages of specific design decisions are not or not sufficiently possible. As far as I know, there has not been an evaluation of various design concepts at the level of entire operating systems in the field of research of the operating systems, which bases these concepts on a truly comparable basis (ie their isolated effect on well measurable quantities such as performance or less well measurable quantities such as the change-friendliness) without the influence of further hidden parameters such as the knowledge and abilities of the respective implementers ¹² ; Since such evaluations appear to be hardly possible according to the current state of affairs, it is instead customary to present the pros and cons of various design alternatives through informal argumentation.

The term "architecture" is used in this work in a broader sense than in many places in the literature (see, eg, [PC75, Jon80, MP81, B ⁺ 95, Lie95b, EKO95, Ass96]) ¹³ , since it has no fixed implementation paradigms "Communicating sequential processes" (see [Hoa78]) prescribes ¹⁴ , nor the question of core sizes and circumference (see [Lie95b]) answered in a fixed manner, nor the question of the Defines boundaries between user address spaces and core or server address spaces, but can solve these questions differently depending on the system configuration, without having to change the source code of the system. Compared to the conventional handling of the architectural concept, the architecture presented here could therefore also be referred to as meta-architecture; However, I have refrained from doing so, since the term "architecture", according to Brockhaus, simply means "architecture", and therefore does not imply the narrower statement that sometimes occurs in the literature. In the sense of "meta-architecture", some conventional architectural issues that have been considered "hardwired" and whose discussion has received much attention in the literature, become dynamic parameters whose variation facilitates a direct comparison of these paradigms in an evaluation ¹⁵ ,

To form a concept: instead of using architecture or meta-architecture, the present design methodology could also be referred to as framework ¹⁶ or as component architecture ¹⁷ . As these terms, according to widespread opinion, are at present very closely linked with the object orientation, which I make possible in the present work, but do not raise to the compelling presupposition of architecture, I have for the time being refrained from such a concept formation. Unlike Szyperskis component term [Szy98] could characterize these proposed building blocks as a lightweight ¹⁸ instantiable ¹⁹ components.

• 1. Universelle Generizität
• 2. Kompositorische Generizität
• 3. Erweiterungs-Generizität

In conflicts between different types of genericity in design decisions to be made, I propagate, at least for use in operating systems, the following prioritization of competing types of genericity:

• 1. Universal Genericity
• 2. Compositional Genericity
• 3. Expansion Genericity

A accurate evaluation of the advantages and disadvantages of this prioritization for the application in operating systems is still pending, at least as long as that here presented concept has not yet been put into practice.

2.2 Separation of mechanism / strategy / representation

In operating system construction, the principle of separation of mechanism and policy has been known and used for a long time; a description of this principle and its advantages can be found eg in [LCC ⁺ 75, CJ75].

Furthermore, independent of mechanisms and strategies, representation has to be considered ²⁰ . For example, a monitor [Han73, Hoa74] can be understood as a programming-language representation of a mechanism that works in principle like a binary semaphore; the programming language representation of a monitor can be simulated in a simple manner by means of semaphores and conventional language means ²¹ . From this it can be seen that the selection of a single representation is sufficient and helps to avoid redundancy ²² ; however, this representation should be as universal and easy to handle / understand as possible. The decision to choose a particular syntactic representation is therefore attributable to pragmatics; this work will not be discussed further; In particular, representation questions are not used to select mechanisms or strategies.

The Differentiation between mechanism and strategy is not always clear possible, as they are from the context and the chosen Abstraction level depends. For example, a strategy can turn back into sub-strategies and sub-mechanisms disintegrate. Mechanisms can also be found in their fine structure in turn contain strategies.

On relatively coarse levels of abstraction correspond mechanisms and Strategies with the hereby propagated abstractions nest and building block in a fairly direct way: a nest represents a set of abstract Mechanisms available A building block implements a strategy or a set of strategies.

The Nest interface provides abstract mechanisms than that the concrete implementation of the mechanisms by late binding (late binding) can occur.

The separation between mechanism and strategy is not only directly supported by the architecture presented here, but also virtually elevated to the principle. Since blocks in turn ent ent other components or using their inputs, the principle of gradual refinement can be applied to the separation of mechanisms and strategies: a building block hierarchy simultaneously functions as a hierarchical-recursive decomposition of the problem to be solved into mechanisms and strategies.

2.3 The responsibility principle

Responsibility and its division is a principle that has been successfully practiced in more complex human societies and systems such as corporations or government for millennia; Responsibilities arise as a result of a division process of responsibility. In the context of operating systems, responsibility was also used as a structuring guideline (without the authors having to be fully aware of this ²³ ): the popular hierarchical structures of the 1970s [Dij68, Dij71] can be obtained, for example, by sharing responsibility the continuation of this idea in so-called "object-oriented" operating systems (for example [K ⁺ 81, Y ⁺ 90, B ⁺ 95, Ass96] and many more), but also the operating systems built on certain fixed mechanisms (eg based on capabilities [NW77, T ⁺ 90 The locality principle often cited in software engineering as a means of structuring systems is ultimately based on the division of responsibility .There are innumerable other examples.

2.3.1 Control flows

One sequential control flow (thread, conceptual description already in [DH66]) characterize themselves as activity carriers, the outside observable only a sequential sequence of (machine) operations performs. control flows are already in [Dij68] for structuring responsibility in Operating systems have been used; this solid connection of control flows with the responsibility for however, certain areas are abandoned in this work. control flows can are used to structure responsibility, but there are it is not necessarily in the architecture presented here firm connection with areas of responsibility (whereby in the individual case also solid connections can be made, but do not have to).

Control flows are considered completely independent of conventional concepts such as processes or mechanisms such as protection areas. Unlike other works, I will avoid the concept of the process because there are several different definitions for it ²⁴ . Since the rediscovery of protection domains (spheres of protection [DH66], protection domains [NW74, CJ75]) in the context of so-called single-address-space systems [C ⁺ 94, Ros94] (see description and protection mechanisms of CTSS in [BPS81 ]), the meaning of the terms has become even more complicated. I restrict myself therefore to the terms control flow and protection area.

Everyone Control flow has a clearly defined at any time Context. The meaning of this context depends on the chosen execution model from: in the simulation of a "process" this would be for example the process image in which the control flow is located and its Performs operations; in the case of single-space or hybrid systems, this would be the most current one Protection. Contexts can be on Requirement to be changed (see [DH66]): a control flow changes thus into another "process" or into another Protection area, which may also be on another computer can. Of these, two different variants are conceivable: one without Saving the old context in the style of switching between coroutines, the other with saving of all contexts in the form a stack with the possibility to return in an earlier Context similar a synchronous RPC or LRPC. A consequence of the change possibility is that the number of control flows in a "process" or protection area is change dynamically and can temporarily become zero.

you It should be remembered that protection areas have a mechanism to carry out and monitoring of security concepts, whereas areas of responsibility one of them in principle independent represent a logical concept for structuring a system. The Representation of areas of responsibility to protection areas is one Question of strategies and can be done in different ways, if necessary dynamically at runtime, solved become.

Control flows, considered in conventional architectures as an independent abstraction. Since their implementation can be done in a separate building block, the treatment as a separate abstraction is not absolutely necessary. Because of its dynamic penetration of the entire infrastructure but you can call them an auxiliary abstraction.

In the following we will look at our operating system for simplicity by default (if not explicitly deviated) neither with the help of process or protection areas, nor of control flows or other activity carriers, but exclusively on the basis of the respectively to be implemented and responsible functionality.

2.3.2 Interface mechanisms

The Overall responsibility of an operating system can be based on a great many different ones Species are divided; my preferred distribution strategies become closer in section 2.4 shown. Any kind of responsibility sharing leads to that modularization limits are introduced into a system, in the case of formalized representation also as interface instances be designated.

The introduction of interface instances for the limitation of module instances creates a distinction between the operations to be performed in caller and processor instances, which are always designated in this way only relative to a fixed interface; The same instance can simultaneously act as a caller or editor for different interfaces. In various distinguishable operations, these roles may be distributed differently, for example, a module instance A may act as a caller to instance B when performing operation op _{1, and} as an agent in op ₂ .

• • RPC (remote procedure call) [BN84, TA90]
• • LRPC (local/lightweight RPC) [B⁺90]
• • Indirekte Prozeduraufrufe
• • Direkte Prozeduraufrufe
• • Makro- oder Inline-Prozeduraufrufe

Mechanisms for passing on the responsibility of a caller to an agent instance are several well-known and proven methods. For example, this may be considered in the order of decreasing overheads or falling costs:

• • RPC (remote procedure call) [BN84, TA90]
• • LRPC (local / lightweight RPC) [B ⁺ 90]
• • Indirect procedure calls
• • Direct procedure calls
• • Macro or inline procedure calls

Some of these example mechanisms are only appropriate for synchronous responsibility sharing, where the caller instance must wait until the end of processing. Asynchronous transfer of responsibility implicitly creates another logical control flow ²⁵ . The asynchronous transfer of responsibility by means of a procedure call is therefore not possible without the use of the control flow concept used (see Section 2.3.1).

you It should be remembered that the question of a parallel or sequentially delegated responsibility is pririzipiell independent of the division strategy into modules and therefore as a matter of concrete implementation strategy the modules can be seen, even if the associated mechanisms not completely (though largely) independent of each other.

Generic genericity relative to the above-mentioned synchronous mechanisms can be achieved directly by uniformly using synchronous RPC at all levels of the system, as this includes the semantics of the other mechanisms as a special case. However, this would unacceptably degrade the performance of a local computer. To achieve universal genericity, therefore, I propose an extension of the method already presented in [Str78]:
Choose a consistent and convenient syntactic representation, such as the procedure call syntax of the programming language used. The binding of instances of these constructs to one of the above mechanisms then takes place either at the translation time of the respective module, or if possible at runtime during the instantiation of a module (the distinction between indirect / direct / inline calls is common today with standard technology ²⁶ not readily available at runtime).

2.3.3 Differentiation of responsibility by encapsulation

in the Software engineering has long been known that testability, Maintainability and many other properties of modules improved if the interfaces are as "thin" as possible and as little information as possible reveal internal structure of the implementation (Pririzip of concealment of information, cf. [Par72]).

This means, on the one hand, that interfaces must always be disclosed, and that the interface between components must have an architecture-dictated form, which building block implementers must adhere to. Everything else should be considered as local variables of a building block. However, the internal implementation of blocks may or should be as far as possible different block instances than local variables (again, no "black interfaces" may be introduced), resulting in an overall tree-like locality hierarchy that is independent of the hierarchical structure of the external building block wirings.The responsibility for the use and operation of local building blocks Instances lies with the implementor of a block The fact of using local block instances is not visible from the outside.

2.4 decomposition and recombination strategies

2.4.1 Disassembly of the be solved Tasks in as possible few universal elementary parts

at In the problem analysis I propagate the application of a simple one Method: it is to ask how generic functionality (preferably in the form of universal genericity) in as few but universal Elemental functionality can be split. Result from this elementary functionality then the elementary operations as conversion into a von Neumann machine model, which is noted in the pseudo-code of an imperative programming language become.

2.4.2 Orthogonality and recombination of elementary operations

in the Ideally, the elementary operations should have the property of orthogonality, i.e. none of the elementary operations should be combined to simulate other elementary operations. A splitting in orthogonal elementary operations can lead to very small, by conventional standards "trivial" elementary operations arise in practice rarely or never as a single person Operations are used, but often only in combination with other elementary operations. Designers often have the concrete programming language representation an EO as a procedure call or RPC in mind and therefore often shy away from the overhead of such a "trivial" decomposition Problem of overhead can be however, largely avoid the systematic recombination of elementary operations as a separate basic concept.

If the recombination of orthogonal elementary operations at the agent instance When the procedure or RPC calls are made, the result is a small one until vanishing overhead compared to direct implementation any combination. The advantage of the decomposition, however, exists in that in the Normally only the program code for the few elementary operations must not be implemented against it for all occurring combinations, often much more numerous fail.

2.5 The problem of "egg legends jack of all trades "

Larger software systems, the above longer Time were used and expanded or for very large application fields and bandwidths often show a phenomenon that is casually referred to as "featuritis". Such all-rounders sometimes have trouble, very simple basic tasks to do in a simple and efficient way. The software structure is compared to simple programs that are just the basic tasks cover, or in comparison to specialists mostly bloated (overhead) and harder to see through.

Around To make this problem manageable, I suggest the use different models in front, between which as possible a hierarchical one Inclusion relationship in the sense that one should prevail Consider model as a special case of another model; often is the less powerful Model also easier. An example of this is given in section 3.2 Access models are treated on nests like singleuser or multiuser become.

A Nest or building block implementation does not necessarily need all of them potential Support models. So you can, for example, with the implementation of the simpler Models begin later and later on when needed expand complicated models or for the more complex models implement alternative implementations (their higher costs then have to not paid by users of the simpler model variant become). Which models of a nest or building block implementation supported in individual cases becomes, becomes as authority (competence) of this implementing instance designated. In contrast, is the behavior (habit) of a concrete caller instance; in order to become the requirements of the competencies of the implementation instance designated.

The Competencies of an implementation instance must be compatible with the behavior of a caller instance be. The competencies and behavior of nesting and building block instances are specified per block type in the form of attributes. The compatibility can then automatically tested during the wiring of concrete block instances with incompatible wiring rejected.

attributes can either static or dynamic: static attributes of a Modify block type never (they hang only of the block type or the chosen implementation), hanging dynamic attributes from the concrete instantiation and / or wiring with other building blocks change but not during the lifetime of a block instance. Values that arise during the Can change the lifetime of a block instance, do not represent any attributes but belong to the state of the block instance.

attributes are used in particular for distinguishing different models and typewritten.

2.6 automatisms

The The basic idea of automation has been successful for centuries used to reduce effort and costs.

in the Context of the architecture presented here means automation, preferably using descriptive methods, to a mechanism automatically trigger, the recurring events automatic processed.

The Implementing many automatisms is a matter of concrete Strategies localized in special building blocks (strategy_ *) should be (see section 4.2.2).

to Creation of building blocks are further automatisms of great benefit, the above the range of functions usual Tools like compilers or debuggers should go out. Lots with the here vorbestellen (interface) mechanisms related construction processes to automate themselves.

For example, the late binding to concrete call mechanisms presented in section 2.3.2 can be automated in the following way:
The programmer specifies a static building block attribute, with which he declares his thinking model with which he has developed the program code. The attribute can take the following values:
code_nolock. The programmer pretends that there is only one control flow that is likely to enter the building block ²⁷ ; he does not care about parallelism at all. As a result, for security reasons, another control flow must never enter the building block, even if the control flow that has already occurred calls for a long-lasting blocking operation.
code_monitor As before, but the programmer is at least aware of the fact that several control flows can occur. Each call to the wait wait operation (see Section 3.3.2) automatically unblocks the access protection against other control flows. The programmer is responsible for observing the effects involved; in particular, he is aware that critical sections are canceled at exactly the point of a wait operation (analogous to the monitor concept).
code_reentrant The programmer is aware that multiple control flows may enter the device asynchronously. He is responsible for securing critical sections and setting locks.

A source-code preprocessor capable of syntactic analysis and knowing the interface conventions extracts this attribute value from the source code and, if necessary (depending on the set call mechanism), automatically generates lock operations for clustering critical sections, case distinction control structures for demultiplexing incoming ( L) RPC calls, and so on. In this way, any programming model can be combined with any interface mechanism ²⁸ ; when static or inline procedure calls are used, the preprocessor hardwires several source texts of different components into a single combo module ²⁹ . With proper careful design and use of well-optimizing compilers, inline procedure calls can almost completely eliminate any interface overhead; This is particularly useful for connecting test and safety devices or smaller trivial devices.

2.7 access rights and protections

2.7.1 Basic View

The Rights management in operating systems is most practical used models [Lan81] on rights relations, the subjects and relate objects to each other; typically leave such relations between subjects and objects are tabulated represent.

I would like to for the Rights management, an approach that is appropriate Interpretation also as a subject-object-schema can be understood, thereby However, any things can be understood as subjects or objects.

• 1. Wer soll natürlicherweise das Subjekt darstellen, das einen bestimmten Auftrag veranlasst?
• 2. Wer soll natürlicherweise das Objekt darstellen, das den Auftrag ausführen soll?

First of all, ask what is to be protected at all. Hereupon several answers are possible. The most general answer is that this is information that needs to be protected. This includes the classic objects (which in any case represent information carriers), but in my opinion means something more. In an operating system there is information that does not necessarily have to be in the form of accessible data objects. Typical examples of this are the set of all possible key values of a secret cryptographic key, or the rights of other subjects (which need not necessarily be explicitly represented), or the competencies or behavior of other subjects, or other subjects par excellence; Subjects can in turn represent objects in another context. Information about objects may also be obtained by reasoning or deriving. I propose, therefore, that instead of the concepts of subject and object we use other concepts based on the following considerations:
The purpose of an operating system is the execution of operations; this is done in the architecture presented here (see Section 3.2 and Chapter 6) by processor instances on behalf of caller instances. Since a caller instance can act on behalf of several other caller instances, two questions arise:

• 1. Who should naturally represent the subject who initiates a particular assignment?
• 2. Who should naturally represent the object that should execute the order?

The first question can be answered in different ways. Therefore, I propose the introduction of another term instead of "subject", namely the mandate, operations are basically on the basis of a mandate, in general an instance (or a subject in previous terminology) can perceive several different mandates, and it can For example, in the real world of law, one and the same lawyer can have different mandates for different clients, and one client can simultaneously assign different mandates to different lawyers or to the same lawyer He may also give the same mandate to several lawyers at the same time, such as lawyers' associations or law firms, mandates may be represented or passed on, and subcontracts may be subcontracted and divided in the legal field For the time being, because of the complexity and consequential effects, ³⁰ The set of all possible mandates should be represented by an abstract data type with a sufficiently large stock of values ³¹ . Mandates have no fixed interpretation, but are only passed between block instances. All operations on mandates such as their generation are thus among the strategies that the implementer of a building block can independently determine. Mandates thus represent another auxiliary abstraction.

The second question can be answered relatively quickly in the context of the architecture presented here: an object is in any case the initial nest instance to which the request to be processed is directed. However, this Nest instance not only decomposes into sub-objects such as individually addressable bytes, but also does not represent all the information that should be protected if possible because of the problems outlined above. The following concept formation comes a little closer to this goal:
Protecting is the execution of operations. The set of all executable operations is called the set of operations; these are all possible combinations of operation identifiers with their input parameter values, or in other words, the union of all Cartesian products of all operation names with their parameter value sets (no matter how many). Also, considering the set of all possible parameter supplies as finite (for example, by limiting the set of all string parameters involved), the amount of operations is generally very large. An equivalent representation is the description as a set of all possible bit strings that can occur in a generic operation nest (see Chapter 6).

A Protection amount is a subset of the operation amount of a given one System. Protective amounts are considered quantities of all (in the sense of any outside defined concept of admissibility) permissible operations to interpret.

2.7.2 Specification of property rights

The term protection amount simplifies the abstraction of any concepts of protection and admissibility in a mathematically very simple and highly flexible way ³² . Since protection amounts are generally too large for a tabular representation, one needs any specification mechanisms that describe them. On the one hand, the purpose of a specification mechanism is to make an amount of protection comprehensible and comprehensibly compressed for human readers, and on the other hand to make the containment problem of the protection quantity evaluable on computers in a memory-efficient manner.

When Specification mechanisms come a lot of concrete realizations (e.g., suitably restricted predicate logics or other calculi) whose discussion goes beyond the scope of this work would. They are also military Protective models (see [Lan81]) or several independent protection models can be used simultaneously.

2.7.3 Examination of property rights

The exam of protective rights can take place in special check modules check_ *, in principle, anywhere on a block hierarchy insert to let. There they have the in the sense of the respective protection model unacceptable Operations back. If you are in special applications such. Real-time controls no protection model needed, One can go to the instantiation of check _ * building blocks completely dispense and thus save any overhead.

The concrete realization of a protective mechanism is a matter of Strategy, at which points which types of tests Based on which mandates carried out should be. It should be noted that at runtime, any block instances newly instantiated and new wiring can be generated with which a solid protection concept u.U. can be bypassed. When used compositional genericity some of the information in the system is in the wiring the building blocks, the highly flexible and dynamically changeable is. To the solution need this problem the instantiation operations of control instances (see section 4.2.1) are included in the respective protection concept and monitored become. For the mathematical description of the dynamic properties of building block networks may be the set of all possible Block configurations that can be generated by control.

2.7.4 Ensuring property rights

• 1. Sicherstellung durch Zugriffsbeschränkung mittels eines Typkonzepts einer höheren Programmiersprache
• 2. Sicherstellung durch die MMU

The literature on protective mechanisms in operating systems mainly uses two mechanisms to ensure a protection concept:

• 1. Access restriction by means of a high-level language type concept
• 2. Secured by the MMU

type concepts Although programming languages have the lowest runtime overhead, i.a. not the measure Security against evasion by malicious attacks, like this MMU hardware allows by physically blocking access to foreign protection areas.

in the Principle can be both mechanisms in the presented here Architecture, although mechanism 1 certainly benefits the increase the reliability a system against accidental malfunctions with low overhead has; However, real security against malicious attacks offers only the mechanism 2.

The Realization of a protection model is therefore based on the classification of the Operating system in protected areas (see section 4.2). In one extreme case, the entire system can be in a single protection area In the other extreme case, each block instance can be executed in one run their own protection area; they are arbitrary intermediates possible. It makes sense to have access rights especially at the borders between protected areas if this effort is to be accepted.

2.8 Performance questions

Not only in the literature, the performance of a system is given a high priority. The high performance goal may occasionally conflict with other goals. By consistently applying the separation between mechanisms and strategies, however, this conflict of objectives can in many cases be avoided by paying attention to their high-performance implementability when designing the mechanisms (however, the performance actually achieved depends, among other things, on the knowledge, capabilities and methods of the implementer ³³ ). ,

2.8.1 Performance of Elementary Operations

In Section 2.4.2 has already been the systematic recombination of Elementary operations motivated out of methodological reasons. performance represents another motif.

caller use elementary operations frequently in bundles, i.e. in successive sequences that determine a programming pattern consequences. bundled Calls to elementary operations include i.A. trivial pattern of program logic: only upon success of the first operation will the next called result parameter of the first operation to the second be passed on. There are many different patterns into consideration.

The idea is to separate the implementation of common patterns (see eg Section 3.3.8) from the implementation of elementary operations. For this purpose, dedicated blocks pattern_ * are suitable, which can be combined with any other blocks. This practically brings about an interface extension, which does not introduce any new functionality, but only serves the convenience and partly also the performance improvement. In particular, when using RPC mechanisms in remote devices, bundling a single operation across a network saves messages and latency when it is first split and interpreted at the server into elementary operations. In order for this to be useful in larger building block hierarchies, relatively simple building blocks such as selector or union, which do almost nothing except pass operations with minor modifications, should pass bundled patterns as suitably modified bundles to the next instance. However, this is not an absolute obligation ³⁴ .

to Implementation of this idea should be a building block in its behavioral attributes specify the patterns he wants to use. The instantiation and wiring logic (control and strategy_ *, see section 4.2) then can the appropriate pattern building blocks automatically at appropriate Insert digits and interpose so that the usability of the patterns in any case, without having to worry about it. If indicates the child building block in its competence attributes, Being able to handle a certain pattern becomes this intermediate step possibly omitted. In cheap make This results in a chain of bundled wirings, which are also over Extends memory hierarchies and so the performance clearly improved.

2.8.2 Zero-copy architecture

Earlier IO interfaces like those of Unix [RT74] or [Che87] had an implicit copy semantics. Recent developments such as [BS96, PDZ99, PDZ00] avoid manufacturing of copies in as possible many situations. It is well known that this dramatic influence can have on the performance.

The The architecture presented here therefore defines the IO functionality of the Nest interface using reference semantics; the transfer of physical storage via interfaces away, this requires anyway. This is copy-free transfer of data over arbitrarily large Block Hierarchies possible. If in special cases a copy semantics desired is or is necessary, it can easily go through as an internal strategy a building block will be implemented.

2.8.3 The Background IO Concept

Rate-limiting bottlenecks often occur in complex networks of building block wiring or in distributed systems. If a fake neck on physical Conditions (e.g., Hard Disk IO), it does not work in principle remove (except by buying faster and more expensive hardware). One can, however, methods develop in order to live better with such bottlenecks, i. to try, "that to make the best of it ".

IO priorities this purpose. IO priorities can be used to separate important from unimportant IO operations. I suggest using the following IO priority levels:
prio_background The IO job can be executed at some point, for example if otherwise unused transmission bandwidth has become free. The waiting time until execution can be any length; no fairness conditions are guaranteed or expected.
prio_normal In principle, the IO job must be processed on an equal footing with other jobs that also have prio_normal. The job must be done after finite time (no starvation). Permutations of the execution order are allowed within these conditions.
prio_urgent The IO job is preferable to others. The greater importance has a logical justification (for example, backing up important metadata).

The The idea is to block orders with prio_background if an IO neck is blocked completely displace. With suitable realization leaves This is done so that background jobs the normal IO activities at all do not bother.

at Hard disks can be realized as follows: first all orders processed with prio_urgent and prio_normal. After that follows one speculative waiting break of the order of magnitude from 10 ms to 100 ms, after which they will be processed the background operations is started. If during this Wait for another operation with prio_urgent or prio_normal arrive, no background operations are started, but the higher prioritized immediately preferred; then the waiting break of front. The purpose of this waiting break is to move mechanically Read / write head can not be adjusted if an application uses its Although IO requests are placed in groups (bursts), between the requirements but very short gaps (for example because of short calculation cycles). Without the waiting break could the mechanical arm of the disk while the very small gap between normal-prioritized burst operations (a few micro- or Nanoseconds) to the position of the background operation which is about 5 ms to 10 on average for today's hard drives ms and then back to the position of the burst process reset become. Since the mechanical adjustment by several orders of magnitude slower than sequential reading of burst data blocks, this would continuous mechanical tailoring to a trashing effect with a breakdown in data throughput. The waiting break solves this Problem by speculation on the arrival of more important Operations. If this speculation after a relatively long time of a few multiples of the hard disk's medium access time not fulfilled has, then it is because of the known empirically observed temporal Unequal distribution of IO requirements very unlikely that just then other IO-operations with normal priority arrive, while the head for the background orders is adjusted. If this case should happen anyway, then it worsens the already very low throughput of the normal-prioritized assignments not much more.

If one the concept of a normal operation practically not disturbing background IO operation in takes up the nest interface, there are new realizations for the Problem of persistence across memory leaks. For example, it damages a buffer cache at all not if you change any Buffer immediately after becoming aware of the change (change to the "dirty" state of the buffer) IO request generated for saving with background priority. If the background job is not running for a long time, then the same effect as with conventional buffering arises without IO job. However, background jobs are called "hot" (i.e., often accessed) Pages executed, then leads this in total to a higher load on the IO channel with orders, fill these however, only the otherwise unused residual bandwidth of the channel, which would otherwise have been "wasted".

in the The end effect is a timely backup of transient memory on persistent background media that automatically attaches to the currently available Bandwidth adapted. With high available bandwidth become speculative Backup operations executed the better security against unforeseen events like power failure lead.

The Background Priority let yourself continue to use for speculative pre-loading of caches, etc. Speculative loads can because of the background priority be displaced by more important foreground activities at any time. The realization Such preloading strategies can be done, for example, by between switched behavioral observer building blocks that perform the IO behavior observe and analyze an application and draw conclusions about it expected future Drag the behavior of the application.

Section 3.3.1 describes in more detail how the IO priority of already issued orders is followed increase. This dynamic change opportunity is important because properly speculated requests can become "real" requirements of an application at any time.

3 nests

The Abstraction of the nest represents a concrete storage model. Operating system designers are traditionally used to them the hardware of a computer or a computer type a specific memory model prescribes or, at least, within relatively narrow limits very close. I try to escape this compulsion in some places so that no fundamental deterioration of the performance characteristics the hardware triggered becomes.

A Nest instance is a logical address space that can run from address 0 to a maximum size (at least 64-bit ³⁵ ). Address arithmetic may be used with logical addresses; bytes ^{36 are} addressed.

One Nest is primarily used to map logical byte addresses physical byte addresses of data blocks. This should u.a. the known Concept of a virtual user address space; however, this is in principle independent of whether MMU hardware is present in a computer or not. A physical data block has a limited length, within which it addresses itself by machine instructions of the processor lets and within whose address arithmetic is driven based on physical byte addresses may be.

3.1 types of nests

It is distinguished between static and dynamic nest: during one static nest similar how a Unix device behaves and only in connection with peripherals or similar should occur the entire rest of the system on dynamic nests.

One dynamic nest can be unlike a conventional file interrogatable and changeable holes in the domain of partial mapping of logical addresses on physical addresses of data blocks, similar to a sparse file under Unix (see also [Fot61, Lie95a]), but this is Property of the entire operating system at all levels except low-level device drivers supports and also used intensively. As a novel elemental operation comes the transparent shift of logical address ranges added. A shift causes a part of the domain the partial mapping of logical addresses to addresses of physical blocks of data is moved so that the same data blocks below an address offset (compared to the previous addresses) in the logical Address range are reachable. In general, by moving operations holes arise in the domain of definition and / or closed, possibly can At the destination of the shift, data blocks are also "lost", i.e. they will not more addressed from the nest (can but i.a. still exist as long as there are still dynamic References exist).

In conventional terminology means a shift operation, that depending on the sign of the shift offset and length of the moved area an insert or delete or move operation in a file, in a database, or generally spoken in carried out a nest becomes. So I'm just using the terms nest and move operation, to characterize these facts. Important to the move operation is that it is transparent. By that is meant that only those Get parts of the overall system from a shift note, which are necessarily affected; for the other parts no changes due to the shift.

For this an example (see also section 4.1.4): from the upper end of a Original nest had been cut out a part-nest. The cut-out operation causes the underlying data blocks both in the original nest appear as well in the cut-out part nest, but there under new addresses (usually at 0 or another fixed address starting). Now find a shift in the original nest, which includes the entire cut-out nest, the entire Extract so be-shifted. Transparency means in this Example, that at the addresses of the cut out part nest nothing changes. Users of the sub-nest do not notice that their host address space is "behind her back "was postponed.

3.2 access models

You can perform operations on a Nest instance, including basic elementary operations. In principle, operation calls can be made in parallel by caller instances (whoever this may be) or asynchronously to an agent instance (usually the implementation of the nest operations). The operator instance causes corresponding operation executions for all operation calls whose triggered effects can influence the execution of other operations. The influence is described by two basic models:
linearize_global Operation execution creates a sequential sequence of nest states on the same nest instance. It is the task of implementing nest operations to ensure compliance with this so-called global operation linearization property ³⁷ (for the basic idea see [HW90] ³⁸ ). Different nest instances are basically independent of each other, unless dependencies are introduced by building blocks.
linearize_local For all operation calls that refer to a mutually overlapping subset of the logical addresses, a sequential sequence of states is defined or established; Operations executions on different logical address areas are not necessarily in an order relation to each other (also called commutability ³⁹ ). In general, this guarantees only a partial order between the operation executions on the same nest instance (local linearization ⁴⁰ ).

global and local linearization differ only in the granularity, with the states be designated; other models are covered in Chapter 7. Only if locally linearized operations with different sized address ranges occur where a larger address range overlaps multiple smaller ones, inevitably arise Semi-circular cross-references between otherwise independent strands of "object" states further refinement of the semantics of nests using additions such as e.g. Building blocks for implementing various types of serializability [Vid87] is possible and heard to the strategies that can be implemented using building blocks. The Model of local linearization is fairly general, to different consistency or correctness terms as specialization to derive.

The requirement for (any) sequential order of nest or address range states (regardless of granularity) can be described by operational semantics. This only determines which operation causes which effects on a nest or address range, ie how a state v _i becomes a state v _j . The states v _i and v _j are also called versions. An operation execution implies the relation of the direct functional dependency between the versions v _i and v _j . In general, j> i, ie the direct functional dependence is a partial order (see 4 ).

The (often desirable) property of the determinant ⁴¹ is given if j = i + 1 holds, ie the functional dependence represents a total order ( 5 )

The Consequence of the (global or local) operation executions hangs per Convention with the sequence of nest states in a 1: 1 relationship together (i.e., each operation causes exactly one version of the nest state, which may be equal to an earlier one Version may fail), even if the determinant is not given should be.

A state v _{i of} a nest instance consists of an address mapping function a _i , which maps logical addresses to physical addresses, and a data mapping function d _i , which maps physical addresses to bytes. We write v _i = (a _i, d _i) and thus express that the composition of the two functions a _i and v _i d _i fully characterized the state. The operations can be divided into the following types of operations:
invariant An invariant operation does not change the state of the nest, ie v _j = v _i .
address-modifying We have d _j = d _i and a _j ≠ a _i . An address-modifying operation causes the same contents (values) of physical data blocks to still exist in the Nest instance, but they are partially reachable under new logical addresses. Address-modifying operations require a dynamic nest.
data-modifying We have a _j = a _i and d _j ≠ d _i . A data modifying operation replaces the contents of physical data blocks with another content in a contiguous area of the logical address space called a modification area; outside the modification range, the effect of the operation is invariant. Data modifying operations can be performed on both static and dynamic nests.

What happens to the states; or what they are used for, is a separate question that can be answered in various ways. I propagate the following models:
singleuser There is only a single caller instance that can make operation calls on the Nest instance. In general, this caller instance can still make multiple parallel (asynchronous) operation calls. The Nest instance assures the caller the determinant. The caller only has access to the latest version v _{n of} the states of the Nest instance, or changes are only made there (single-copy property). Multiple parallel operation calls by the same caller do not guarantee a specific order of operation executions. However, if the caller always orders only one operation call, it will be guaranteed a specific order.
multiuser There may be multiple caller instances. These are guaranteed the property of determinacy. Compared to the single-user model, a single caller instance, despite having been assigned a single operation call, no longer guarantees the order in which it is executed compared to the orders of other instances.
multiversion This model is discussed in Chapter 7 and breaks down into several submodels. There may be several caller instances. In the most general submodel, these have potential access to all address versions a _i and all data versions d _{j of} a nest instance, thus allowing access to any pseudo states v ' _ij = (a _i , d _j ) in which i = j does not necessarily have to apply (which may be required in some submodels). Thus, only the assurance is given that the operation execution takes place on any valid (not on an undefined) version of the address and data mapping, but which may also be older.

The Models singleuser and multiuser fulfill by design the property the determinant, so have the semantics of semiconductor or disk storage, where a write operation replaces the previous version and no longer accessible power. In the following we will confine ourselves to these two models and View the multiversion in Chapter 7 separately.

The property of correctness is not considered by the nest models described here ⁴² ; the problems involved have to be solved at a different level. This allows concrete building block implementations to meet different models of correctness based on the more general nest abstraction. Each caller instance therefore has the obligation to itself ⁴³ to fulfill further assurances given by itself, in particular the correctness (in the sense defined by itself). However, the abstraction of the nests provides a (hopefully convenient) infrastructure for this.

A Nest implementation does not necessarily need all three models too support. Which models are supported in the individual case, belongs to the Competencies (see Section 2.5) of the Nest implementation. As already said, must Compatibility of the nest implementation with the behavior of a caller instance be.

The Table 6 shows the possible Compatibilities. The triples here mean how many different caller instances with behavior of singleuser, multiuser and multiversion respectively a configuration with a nest implementation of those Competence to participate. While Singleuser is incompatible with any other caller behavior multi * arbitrarily miscible with each other, provided the nest implementation can play their competences.

3.3 Elementary Operations on static and dynamic nests

Of the is here presented set of elementary operations on nests as an example to understand how to nests the interface can shape. The description is informal and should be the core idea to explain; it is not a complete specification of all details.

The design of IO interfaces is complicated in practice by a variety of circumstances, which in my opinion are responsible for much of the implementation complexity of real-world operating systems. By taking these circumstances into account in the interfaces and throughout the system across all levels ⁴⁴ , as well as by supporting so-called "advanced IO concepts" such as asynchronous IO and non-blocking IO using universal genericity, this complexity can be reduced ^45. Therefore, it already contains the interface for static nests all IO concepts occurring in the system.

In the following draft, I also tried to take into account the requirements of databases so far, hopefully, to cover the basic functionality of a database system ⁴⁶ .

Locking mechanisms serve to limit the possible execution sequences of operations. Locking mechanisms in static and dynamic nests are the basic lock and unlock operations, which are the only locking mechanisms required throughout the operating system ⁴⁷ .

One static nest settles as a restriction understand a dynamic nest where the move operation missing and no holes in the domain of definition, and in most cases (eg with hard disk partitions) no dynamic change of the size takes place. However, this abstract view does not become fully up to date with reality peripherals divided: the granularity Data transfers are firmer on blocks at current peripherals Length, about 512 bytes for hard drives or 2048 bytes for CD drives, limited. About that allowed out Data transfers only take place at such addresses, through the granularity are divisible without residue. These restrictions are indicated by an attribute modeled transfer_size associated with each Nest instance, and that each user of a nest query and take into account in his IO jobs got to.

at static and dynamic nests provide the EO for this, that the logical addresses (which are relative to the respective nest) be translated to physical addresses of transient blocks of data. The responsibility for the Management of physical addresses can be regulated differently. Therefor Two modes are supported, which are mixed in principle usable: logical IO and physical IO.

At the logical IO happens the administration (seat reservation and release) the transient data blocks in physical memory through the operation get while while physical IO for that the caller himself is responsible. Physical IO should ideally only be used on the lower layers of device drivers, the rest of the system usually uses logical IO. The differences between both modes are low and are only by expressed a different parameter supply of get.

The Elementary operations not only wrap all together Asynchronous IO, but also allow the transparent use a buffer cache without change the interface. As we will later see, lead They also go through the memory management functionality of the system, even that of paging virtual user memory pages. Out The following description of the asynchronous IO model results the realization of synchronous IO and nonblocking IO on trivial Way, so I will save their execution.

7 gives an overview of the elementary operations on static nests: As can be seen, the elementary operations are always pairwise combined with an opposite or nullifying operation. Different types of IO or other types of access to nests arise through a layer model, which is briefly outlined here from inside to outside:
In the simplest case, physical IO is operated by the operation transfer. The functionality of synchronous IOs is created by waiting for termination via wait. With asynchronous IO, the call to wait can also be dispensed with. With logical IO, the mapping from logical to physical addresses is taken over by the operation get. The pairwise call to put solves the resource management in a similar way to a conventional buffer cache (internal use of reference counters). In order for an output of a block to be wired in parallel with several inputs of other blocks (multiuser competence), the mutual exclusion (see [Lag78]) is provided in the case of parallel access by the lock and unlock operations. For the reproduction of pipes and the like as well as for memory management, there are further elementary operations get address and put_address with which the problem of the atomic reservation of address ranges can be solved, in particular in the case of several parallel accessors.

3.3.1 transfer

This elementary operation causes an update operation to be ordered in one of the two possible directions between the logical address in the nest and the physical data block (without waiting for execution of this operation). Such an update operation is called synonymous IO-operation or IO-Aufrrag; Instead of the term IO operation execution, the term termination of the IO job is also used synonymously. Different IO jobs are basically independent of each other. The interface looks like this:

The direction parameter can take one of the following values:
read Updated from the logical address in the nest to the physical data block. Upon successful completion of the IO job, it is assured that the latest version is at the physical address.
write The update takes place in the direction from the physical data block address to the logical address on the background medium. When the IO job is executed, an amended latest version of the nest state is created.
stop A possibly already waiting IO job is removed from the queue of waiting jobs, if possible; This is usually no longer possible with IO jobs already running. The consequence is that the assurances given by the other direction types no longer have to be respected. If a read job was aborted, then max_version is undefined.

Of the IO job takes place with the io_prio priority specified in section 2.8.3 in more detail explained becomes. As a rule, orders with a higher one IO priority before those with lower priority; Exceptions are possible if this increases the overall throughput of the IO system. Of the Parameter depend allows the specification of a partial order between IO jobs especially for the implementation of crash-proof atomic operations or transactions needed becomes. A list of those logical addresses is given, their associated IO jobs (if they exist) definitely have to be finished before the current IO job is executed (physically started) may be.

If transfer to an existing IO job should a double entry of identical orders should be avoided; instead of of which only an internally assigned reference counter is increased (this must first be available from multiuser competence): This is a flooding of the IO system by unnecessary IO jobs even with mass use of background IO (see section 2.8.3) prevented. Possibly. becomes the IO priority of an already waiting job raised to the new level, so that in the future with a more timely Processing will be expected.

in the boolean result parameter success is returned if a successful Generating the IO job possible was.

3.3.2 wait

This elementary operation implements medium term maintenance. The interface looks like this:

If the Boolean parameter pause was set and (still) an IO request does not exist yet (physically terminated) is waited for the termination. The Boolean parameter keep determines whether the internal reference counter of a existing order (even after successful completion) be or should be decremented; when leaving is a status query by subsequent wait operations of the same caller instance possible. By appropriate combinations of pause and keep parameters Polling is possible. Assignments, their reference counter to 0 may or should be removed.

The result parameters min_version and max_version report the actuality according to the following classification:
undefined The content of the data block at the returned physical address is undefined.
newest The Nest implementation assures that the latest version of the Nest state was delivered in the data block that was valid at the time the operation was executed. Unless blocking mechanisms prevent the execution of further operations, there is no guarantee that in the meantime between Operation execution and the inspection by the caller instance no further operations executions have taken place, which have changed the nest state in the meantime.

Between These values are based on the relation undefined <newest. Furthermore, min_version ≤ max_version applies. The value of min_version means that the nest implementation of which it is certain that the data block is at least the specified one topicality has. Conversely, max_version means that the nest implementation It is certain that the version does not exceed the specified actuality level. For example, if the nest implementation does not do anything about the topicality White, then min_version = undefined and max_version = newest. Only if min_version = max_version = newest, the data block is up to date. From min_version = max_version = undefined it can be concluded that either no IO job (anymore) exists, or that its Effect has been canceled by transfer in stop mode, or that the transfer operation was technically unsuccessful (write or reading errors).

3.3.3 get

One Buffer cache manages a transient internal mapping between logical and physical addresses. This assignment is transient, i.e. It is valid for the longest for the Period in which the operating system is running, and can be resolved again, as soon as there are no more dynamic references to the physical data block consist. Nevertheless, the assignment should possibly exist for a longer time than the Caller necessarily required. Without the possibility of storage one time longer permanent association between logical and physical addresses would be one Caching functionality not or only difficult to fulfill.

The elementary operation get therefore manages a transient internal mapping between logical and physical addresses. The interface includes the following parameters:

The handed over Addresses need for successful implementation be divisible by transfer_size, the length must also be a multiple represent it. As a result, the physical address is returned, if the operation was successful, otherwise a NULL address. The returned Length may be shorter than the requested length (for example, if the underlying IO system has no transfers with the desired Length at Can perform piece), but it must be divisible by transfer_size.

The Nest Instance searches atomically for its internal allocation structures (for example, fast hash tables), whether already assigned to a physical data block at the desired logical address exists. If so, then this address and the possibly shortened Length returned.

If there is no room for a new coherent one Data block of length len or, if this is not possible, as far as possible greater Data block up to the length len (in multiples of transfer_size). Finally, the address and Length in the assignment structures are entered and returned. The result parameters min_version and max_version are defined as in wait.

Physical addresses of data blocks represent aliases that can be shared by multiple callers as of multiuser competence. However, it is not guaranteed ⁴⁸ that different caller instances will get the same physical address back at the same logical address ⁴⁹ . The use of physical addresses is done by machine instructions, which are independent of the operations of the nest implementation and can in principle lead to interference due to the aliases, if certain rules are not observed. The rules are as follows:
Each returned physical data block is assigned a reference counter from multiuser competence, which manages the number of references existing on it. A call to get, which finds an existing data block, increments this reference counter. If a new data block has been allocated, the reference counter is regularly at 1. The physical data block is logically released by the later-described operation put, which decrements the reference counter again and must therefore always be called pairwise (equal number of calls). The mandate parameter is only needed from the multiversion model (see chapter 7).

The boolean parameter mode specifies whether the caller may then use the data block for write purposes. Some implementation paradigms (see Section 2.7) use this information to detect and sanction violations of the regulations. From multiuser competence is noted by another internal reference counter, how many callers had set the mode parameter.

If several callers have set the mode parameter, they can in principle execute their own modification operations on the physical data block independently of one another, which can lead to interference ⁵⁰ if they do not take further action (eg by setting Locks ⁵¹ ).

3.3.4 put

This operation atomically decrements the internal reference counter associated with each physical data block. The interface is:
put (nest, mandate, phys_addr, mode)

If the reference counter by this operation becomes 0, then may originally by get mapped between logical and physical addresses again resolved in an atomic way and the storage space for the data block are released. However, this should be possible only happen when there is no memory. After the last put have requests to the physical address no longer relevant to the caller instance.

If any instance makes accesses to a physical address that no meaning (anymore) for her has, then this is considered a mistake. If errors are not intercepted and could be prevented (see Section 2.7), then can be considered As a result, the entire system is in an undefined state. All instances therefore have a duty to avoid mistakes.

By the parameter mode becomes the internal reference counter for the number of recorders managed; Callers have a duty to match this parameter in pairs to use get's mode parameter (violations apply as a mistake).

3.3.5 lock and unlock

Locks limit the possible execution sequences of operations. The locks used in our model not only work against other locks, but also against some ⁵² other elemental operations. In principle, implementations of building blocks must take care of the realization of any correctness terms themselves by making the possible execution sequences of a nest instance compatible with the permissible execution sequences of their respective correctness term. Although this burdens the module implementations with the obligation to provide for this compatibility itself, but allows for much more flexible correctness models. Once a lock has been successfully set, the respective execution instance (nest implementation) guarantees its compliance with the caller instance. In addition to the basic functionality of an operating system, the locks proposed here should also cover important areas of the functionality of databases and transactions (see eg [Dat95, EN95]). The model presented here should be understood as a suggestion that can be improved in some places (for example by introducing intentional locking types).

The lock and unlock elementary operations lock or unlock areas of the logical address space from other caller instances of the lock operation or to other mandate owners and to get; held locks are always assigned as the calling entity or the mandates described in Section 2.7. The locked areas do not necessarily have to be present in the definition area of dynamic nests ("phantom locks"), so there is no synchronization on data objects, but one on logical address areas: lock operations that are executed on mutually non-overlapping address areas Locks are not recursive, but accumulating within the same lock-type. It does not hurt if lock-in areas already obtained are requested again from the same instance or under the same mandate, but it will not do anything The unlock does not need to have the same address range as the previous lock, which means that it is possible to turn a locked original area into smaller sections with intermediate shared areas, and conversely, unlock a larger area using unlock s was previously locked using lock; For example, if you call unlock with the entire address space as a parameter, all locks held by the calling instance or the mandate are released atomically at one go (strict two-phase commit). The parameters are:

The blocked address range is specified by the parameters log_address and len. The try_address and try_len parameters describe a trial address range that must represent an upper portion of the lock address range. If the trial address range is really larger than the blackout range, then the nest implementation only needs to take it into account in the result lockout area locked_address and locked_len, as is possible without additional waiting. Further explanations for the possible speculative locking can be found in Section 5.3. The result blocking area either comprises at least the blocking address range (ie it lies between the blocking and the trial range), or it has the length 0. In the latter case, it was not possible to set the lock (see below). The parameter kind distinguishes between the well-known types Read-Lock and Write-Lock ⁵³ and further refined Lock types. It has one of the following values:
read The result-inhibited area is then protected against overwriting of the d _i component by other caller instances of lock and get in write mode ⁵⁴ .
write The result lock area is then reserved exclusively for the caller to override the d _i component.
upgrade Like write, however, an already set read-lock is atomized to a write-lock (if possible); this mode is required on some transaction models (especially pessimistic models) and should be used with caution outside of this application ⁵⁵ .
fix The result cut area is then protected against changes in a component _i by other callers instances.
reorg The result lockup area is then reserved exclusively for changing a _i component of the caller.

The Types of fix and reorg correspond in their semantics to conventional ones Types read and write, but they refer to modifications the address ranges (e.g., by move).

The action parameter describes how the lock operation should handle the desired lock. He has one of the following values:
ask It will only be checked if it would have been possible to set a corresponding lock without blocking. The returned result exclusion area may participate in races with other callers of Lock and should be treated accordingly with caution.
try The lock is set atomically if it is immediately possible without blocking. Otherwise, the length 0 is returned.
wait The lock is set, even if it only needs to wait for release by another instance. The return delivery of locked_len = 0 is still possible, especially if there is a deadlock. The result must therefore be checked by the caller in any case.

Limiting the possible execution sequences depends on the competencies of the Nest implementation. Singleuser does not need to implement locks; multiversion is covered in Chapter 7. For multiuser, the compatibility table looks like the operations in 8th shown off. The first letter of the header name denotes the operation g = get or l = lock. The second letter denotes the lock-on r = read, w = write or u = upgrade. In the case of get, the second letter refers to the mode parameter. Consider the logical address assignments of all held data blocks that overlap the requested lock range.

In the table, + means that the operation goes through without waiting if it encounters the other one, and - means waiting for the other operation to be canceled (ie, a restriction on the possible execution sequence takes place). The * signifies that it depends on whether the other operation was initiated by the same caller instance; if so, then you do not wait (otherwise a deadlock would occur immediately); if not, then you have to wait. At those positions of the table where one stands, the other operation, if different from the current one, may not have been executed by the same caller instance, but only by another ⁵⁶ .

The lock types fix and reorg are intended to protect against the effects of the address-modifying operations move, clear and delete described later, so these are given in the table in 9 considered. In the Heading means m = move or clear or delete (any address-modifying operation). The final letter f means fixed, g means reorg. As you can see, the address change locks work in a similar way to the classic read-write locks, except that they only refer to the a _i components of the states.

The implementation of lock and unlock must be designed internally in such a way that no locks are required for a separation into spinlocks and control flow (see [K ⁺ 91, LA93]), and furthermore a use through interrupts is possible (cf. [KE95]).

3.3.6 Voluntary self-control Of the behavior

A Nest implementation guarantees lock-free behavior and protection against interventions by other instances, even if others do not comply with locking conventions. However, this guarantee only benefits a caller instance with multi * behaviors when it actually uses the locks - those who "forget" are themselves responsible for possible consequences, but in a more complex system there are errors that are missing or incorrectly set locks can be extremely difficult to reproduce and find. Therefore, each building block implementation should be self-controlled by means of the table in its behavior 10 check. Here g = get and l = lock. The last letter has the same meaning as the compatibility tables. The rows indicate the first operation, the columns the second operation. Both operations refer to the same instance that invokes them. The table is therefore not symmetrical as the previous tables, but shows the importance of the order of operations. In the table! Means that the second operation may only be called if the first one has already been executed (and has not yet been canceled by a counteroperation). If more than one! emerge, then it is enough, if one of the first operations was executed before. The & signifies that the first operation in question must have been executed additionally, one of the operations marked with & being sufficient. The sign ¬ means that the first operation may under no circumstances have been previously called, or that it must have been canceled in the meantime.

Even though This behavioral self-control is voluntary, it becomes de facto as standard for considers the behavior of all building blocks; Exceptions are e.g. to Inspection of any conditions or permitted for statistical purposes, but should be justified (for example, that the process in question is inherently wet-endangered anyway). The self-control can e.g. through internal use of a test module done, which reads all operation calls and in case of injury the table outputs warnings or error messages, if necessary also tougher Sanctions applies. Because the information about Locks kept on each Case in the agent instance of the Locks must be led, offers itself these also as a place for the high-performance implementation of delegated to them Control. If the task is extremely demanding the performance provides, the self-control at the expense of increased error rate also be turned off.

3.3.7 get_maxlen and set_maxlen

• get_maxlen (nest) → len
• set_maxlen (nest, len) → success

In order to let yourself the maximum length query (maximum usable address plus 1) of a nest or put. With some (rather rare) devices can be this length change (e.g., tape drives by writing an EOF mark or the like); on most devices lies the length however, physically.

Greater importance has set_maxlen in dynamic nests, where both reductions as well as enlargements give the semantics of delete in the affected areas (see Section 3.4.3).

3.3.8 Stream IO, pipes, Sockets and memory management

The Elementary operations described so far solve the problems of portionwise Access, asynchronous IO over Memory hierarchies, and the associated memory management. However, this only works if the logical addresses are known are where IO is supposed to happen. For purely sequential IO, like he e.g. occurs on sequential streams, pipes or sockets, conventional interfaces do not use addresses in the interface.

Nests can be executed to simulate pipes and sockets as ring buffer ⁵⁷ (with length described by get_maxlen). Logical addresses are used in the interface, but they are assigned and managed not by the caller but by the implementation instance of the nest operations. Thus, other uses and combinations are possible ⁵⁸ , especially the lookahead on not yet finally consumed data.

The Problem of atomicity The reservation is a special property of pipes, sockets and regular Files in append mode. Parallel write operations interfere not each other and overwrite not, but lead ultimately always to any serialized sequence of write operations (also if the specific order i.a. is not determined). As well when reading from pipes and sockets is guaranteed that one and the same data will arrive at one of the readers just once (even if the specific recipient again not determined). When transferred to nests, it means that no races between different caller instances (e.g. Processes) in the inspection of changes in the address mapping may take place. On the other hand, if you did not finally consume the lookahead Allow data wants, then you have to make such races again (It is then the task of the consumer, with the associated To handle effects correctly).

To solve the atomicity of the reservation problem, I propose to introduce the operators get address and put_address. The interface looks like this:

The both length parameters indicate the minimum and the maximum of a reservation request. The boolean parameter where indicates whether the reservation is currently Undefined range of address mapping should take place (write functionality) or in the defined area (read functionality). If action = wait and reservation of the minimum length is not possible, the call blocks until at least the minimum reservation is possible (long-term waiting). The Boolean parameter lock determines whether several callers in parallel each have a reserved address range allowed to receive or if more applicants wait until the next put_address have to.

As a result, the address of the now reserved area is returned and its actual length, which may be between the minimum and maximum requirements (in multiples of the transfer_size); 0 will be returned if failed. The Nest implementation assures atomicity of the reservation to each caller instance by always dispatching disjoint address ranges in parallel calls to get_address. The caller then has knowledge of an exclusively reserved for him address range, with the help of which he can read or write blocks of data, and / or make changes to the address mapping using clear or delete (see sections 3: 4.2 ff.) ⁵⁹ .
put_address (nest, len)

lifts the reservation back on. Every caller of get_address has the duty, once a received address range again release using put_address; the timing and the order remains basically open.

The standard pipe functionality is achieved by the following procedure:
Reader: the caller first executes get_address, then get in the received address range; if the actuality of the data is not yet available, transfer follows in read mode and wait. After processing the data, delete, put and put_address follow.
Schreiber: the caller first executes get_address, then clear and get. After filing the data will follow transfer imwrite mode, put and put_address.

If a writer or reader does not consume or provide the data for good If he wants, he can do without delete or clear, respectively Address space operation by a compensation operation before pick_address pick up again. Whether and how much data is actually consumed or are provided by change operations only of the definition area indicated by the reservation as well may deviate downwards. The standard case of a full exploit should be through the Concept of systematic recombination of elementary operations efficiently (see section 2.4) to let.

If the parameter lock is not set, the actual assignment of the address space by clear or the clearance by delete can also take place in a different order than the order of the address reservation specified. It can even happen that no completely contiguous defined address range arises if some of the callers for get_address forego or reverse the corresponding manipulation of the address space. This may result in losing the ordering relationship of the data packets, which is necessary in pipe functionality, but offers the possibility of out-of-order treatment for other applications ⁶⁰ . Leaving out the transfer operations gives you non-persistent semantics. This can be used to emulate the functionality of a memory heap. Therefore, this interface is also suitable for any memory management, even for fixed size internal objects ⁶¹ .

3.4 Elementary Operations on dynamic nests

dynamic Nests contain all the operations of a static nest as well additionally the following address-modifying operations. You have with the scrappiness the domain of the memory map and with the shift operation to do.

If is trying on holes to read or write in the domain of a nest Error codes returned. This distinguishes nests from the semantics of sparse files below Unix. If the latter semantics is desired, this is relative easily implementable by an appropriate adaptation module.

3.4.1 get_map

These Operation provides information about the defined areas of a dynamic nest. conceptional this is a list of pairs, where each pair is the logical start address of a defined area and its length. represents This list is preceded by an array of pairs, following the starting addresses sorted in ascending order. For the efficient search for addresses can therefore, for example, binary Search to be used.

Because such an array can become very long in extreme cases, get_map does not return it directly, but instead returns a reference to another Nest instance that contains that array and is read-only.
get_map (nest) → nest

The nest instance returned by get_map is called an adjoint nest. It contains the domain of definition of the original nest in the representation described above. Adjacent nests, in turn, have no holes, ie their adjoint nest has only one trivial structure with a single entry ⁶²

These solution has the advantage that the internal administration of the domain can be done by local building block instances that adjoint Manage Nest directly. Extensions and deletions in the definition area in this case, can be directly by move operations on the realize adjoint nest. Otherwise, implementations of Nests their domain of definition in any other way realize internally, provided they are a virtual adjoint nest to disposal that dynamically generates its content on demand.

The list contained in the adjoint nest is of particular importance in the case of devices with dynamic block or sector sizes (in particular, tape drives where each data block can be of individual size, or other character-oriented devices that require the length of individual transfers). , for pipes and network sockets, where the packet size of a single original entry must be determinable by the receiver ⁶³ . In all these cases, the adjoint nest represents densely spaced address areas (with no gaps in between). Thus, each user can decide for himself whether he wants to make a Unix-typical access to the nest in disregard of the original packet or data record limits, or whether he wants to first look at the packet or record boundaries in the adjoint nest and take into account accordingly.

A dense juxtaposition of defined areas is also possible with persistent nests. However, users are encouraged to avoid this in the field as much as possible, since it could lead to communication problems with the file paradigms of other current operating systems ⁶⁴ . Conceptually, one is Nest is therefore much more than a file under Unix, because it is inextricably linked to its domain of definition, which is represented in the presented architecture in an adjoint nest.

When representing a Unix or Windows file in a nest, the associated adjoint nest contains only a single entry with the starting address 0 and the length of the file ⁶⁵ . The maximum address accessible by means of get_maxlen and set_maxlen has only the function of a safety barrier similar to a quota, which says nothing about the actual space requirement and can easily assume values such as 2 ⁶³ -1.

3.4.2 clear

In order to becomes the domain of a nest at the specified location and length expanded, as far as there was previously a gap. If subsequently in In this area of the address space, zero-byte data blocks appear.

This applies even if previously blocks of data in the affected area were assigned in whole or in part. In this case already stay still usable by means of get delivered data blocks, however will be later remote or already buffered transfer operations on these blocks not really anymore executed. After final Release by put such orphaned (orphane) data blocks immediately used for storage recycling.

There a get too blocks with multiples of transfer_size that can be delivered by one subsequent clear may only be partially affected, the internal logic of the nest implementation must ensure that in subsequent operations (especially put and transfer) the unaffected part of such a block as a normal block, the affected part is treated as orphaned.

If clear touches an already defined area or with it whole or partially overlapped, then by default one finds Extension or merging of the definition areas in the adjoint Nest instead. Possibly. be holes also completely filled and adjacent areas merged together to form a larger area.

By Setting the Boolean mode parameter allows this standard behavior so modify that just at the borders of the clear-field entries in the adjoint nest so created or changed be that the area as a single data packet with possibly complete Connection to neighboring areas (possibly resulting from this) appears. If previously defined in the clear area several smaller. Areas were located, then they will go through this clear variant also "flat made".

3.4.3 delete

• delete (nest, log_address, len) → success

These Operation causes at the specified location and length Hole in the definition area or existing holes be extended. If affected data blocks previously by means of were used in whole or in part; then These are used in IO operations and memory recycling analogous to clear treated as orphaned.

3.4.4 move

An area of the address space designated by the given address and length is shifted by the offset (positive or negative). The content of the moved data blocks is not changed, only the assignment of logical to physical addresses is changed. Blocks already delivered by get, which lie completely in the source area of the shift, remain valid with their physical addresses, but their internal transient assignment is adjusted according to the shift. At the Later, they are treated as if they have always been at the new address. The source and target areas of the shift may overlap independently of the shift direction ⁶⁶ ; In contrast to fixed and reorg locks, both areas should be regarded as relevant, even if they do not overlap. In the freed source area a hole appears. If there are already defined areas in the target area, these are "hidden", and data blocks already delivered by get are treated as orphaned in the same way as delete Any existing holes in the source area are also moved, the release of existing data blocks in the target area takes place even if only a hole was moved there ^67. If blocks were already requested by means of get before the move, which were completely in the source area, then they are then treated as if they had already been in the target area at the request Transfer_size, which are only partially affected by the move, must have the internal management logic split and handle the internal transient assignment separately, so that the following parts of operations, such as put or transfer, are treated as if they were not originally requested in one go n.

A efficient realization of move is possible and will be described in section 4.1.3 (module map_simple) closer detail.

3.4.5 get_meta

• get_meta (nest) → nest

to Management of meta-information about The state of a Nest instance may be that of an auxiliary Nest instance be assigned, which is called meta-nest. If the meta-nest does not exist, a NULL flag is returned.

Meta nests are meant to provide information about a nest, analogous to file attributes or inode information (see [Bac86]), but not exclusively limited to these uses. Meta-nests will be in section later 6.1 play a prominent role in the introduction of type systems, also in Section 4.2 in the auto-instantiation of building blocks and in Section 4.1.5 on the locality properties of accesses on directory hierarchies.

One Contains meta-nest only a single defined area without holes, ideally only should take up relatively little space (i.e., it should not Storing big Amounts of data are misused) in order to achieve a high-performance access behavior sure. Because of the intended smallness should be a meta-nest support a transfer_size of 1.

at a persistent original nest must have the associated meta-nest, if it exists, also be kept persistent. If crash-proof atomic transactions must be implemented, the meta-nest in terms of this semantics are treated as part of the original nest. Meta-nests can be basically continue to represent use static and dynamic attributes; this leads to a Simplifying the concepts to be implemented makes the presence (virtual) meta-nests but mandatory.

4 blocks

A block instance (see 11 ) is an object that has any, possibly even at runtime, changing number of inputs and outputs, which in turn each represent instances of nests. Blocks are drawn as boxes with left-side inputs and right-side outputs, similar to the electrical and digital technology. A wiring rule is that inputs can only be linked to the outputs of other blocks and vice versa, whereby an input may only be linked to a single output, whereas an output may be linked to several inputs.

Outputs thus provide nests to other devices, the inputs of which are to be considered as consumers of the services offered by the outputs; So we have a system of producers and consumers in the logical sense. A wireline represents a hierarchy relationship ⁶⁸ between an upstream building block (producer of the service) and a downstream one (consumer of the service). By convention, we define the direction from the producer to the consumer as the "current direction" of a wiring line, but this has nothing to do with potential Data flow directions to do, because the current direction is at the same time the logical data flow direction in reading, but the logical write data flow direction counteracts (which at the beginning can lead to confusion, as well as the in-house transfer of operation calls, the internally mostly from the outputs to the inputs runs). A line provides all operations that are provided at the output of a block to one or more consumers. Since this also includes the get_map and get_meta operations, this makes the associated adjoint nest and meta-nest available.

sense The building block is different transformations of both the address area as well as possibly the content of nests, occasionally also of the associated Meta-Nest or Nest attributes such as transfer_size or Perform access models. By combining the building blocks to form complex networks transformation possibilities, the with conventional Operating system architectures are very difficult to implement.

building blocks have at least one instantiation and constructor operation, with which new instances of the respective block type can be created with the parameters of constructor operations i.d.R. Block-specific are. The destructor operation, on the other hand, has a uniform interface. Some building block types have it In addition, more specific operations that affect their behavior (about the number of inputs and outputs) can be controlled at runtime.

An automated verification of the compatibility of the outputs of the outputs with the behavior of inputs takes place in the wiring operation; For example, the matching of the transfer_size attribute is checked. More details in section 4.2. Many of the modules presented below can be implemented in different stages of development ⁶⁹ and with different competences and behavior.

4.1 example block types

At the Design of building blocks should be taken to be as possible little redundancy to the functionality already existing block types occur. Sense of decomposition Building Blocks is the total tasks to be solved in an operating system in as possible many, small, of each other as possible independent (orthogonal) Parts and responsibilities split.

I I tried at the here to be understood as an example decomposition as possible only to provide such tasks as in other current operating system designs (including network operating systems) or appear somewhere in databases and there with some high Costs ad hoc solved become. With that would like I show that a component decomposition based on the abstractions Nest and building block the total effort of the tasks to be implemented reduces, since already the combination of few reusable Building block types a mighty functionality generated.

4.1.1 device_ *

These building blocks (see 12 ) usually have no input ⁷⁰ and exactly one output, with which they provide the content of a device (for example, device IDE for IDE hard drives) as a static nest to any consumers available. In terms of the wiring logic of the blocks, they represent producers or "data sources".

A principal distinction between block and character devices as with Unix is not necessary because of the design of the nest operations both paradigms and the operating modes occurring in them uniform Way supported; the difference only becomes the value of the transfer_size attribute displayed.

Typically, device drivers are used to transfer data blocks to peripherals, and thus only need to implement the static nests operations and single user competencies ⁷¹ only. An at least multiuser-capable special form is device_mem, which provides transient memory without transfer operations by implementing the get_address- and put_address operations. To manage storage with different transfer_size values, multiple instances of device_mem form a wired hierarchy where small granularity managers "borrow" storage from an ingress with more granular managers (see Section 5.1) "of physical memory has all the memory at startup of the operating system and therefore has no input ⁷² .

Another multi-user-capable special form is device_ramdisk that implements a limited persistence that is not about power outages across extend must ^73rd

4.1.2 buffer

A buffer block (see 13 ) decouples activities between input and output (in both directions). It is suitable for adapting the temporal access behavior between slow and fast block instances; Ideally, it should be the only place in the system as a whole to solve the problems of the so-called "memory gap".

One frequently Use case is the follow-up behind a device_ *. These are often required only the operations of static nests, and the Input only needs to show singleuser behavior; also the exit just needs to provide single-user competence as most common Use case, only a single map_ * instance is followed. But there are also applications where at least multiuser behavior and competence needed especially the downstream connection behind a remote device (see section 4.1.12).

at the implementation of multiuser behavior occurs in the literature known problem of cache coherence (see [AB86, LH89, HP95] with an upstream instance. Through the notify_ * operations provided in the nest interface (see Chapter 5) this is relatively easy to solve.

If considering buffer building blocks as the only place in the whole system, the decoupling problem of temporal access behavior triggers, and Although it dissolves very efficiently, then you can go one step further: you can almost implement all other blocks internally stateless, or at least largely stateless. A building block is stateless when it belongs to each Time in which there is no logical control flow in it, destroyed and subsequently can be reconstructed without this being a changed Behavior from the outside becomes visible. Statelessness allows a significant reduction the inner complexity many building blocks compared to conventional implementations, because the responsibility for the correct preservation of the internal state information delegated to a child building block; therefore is statelessness highly desirable. It assumes, however, that accesses via a so decoupled interface cost almost nothing. By default use of procedure calls as an interface mechanism and through the Zero-copy architecture (see Section 2.8.2) makes this possible.

For the caching of data blocks the main memory is used; this must be shared by multiple buffer instances. The problem involved could be solved outside of the wiring system of the building blocks (first picture). However, the following solution has advantages:
The input designated with slow is intended to decouple the access frequencies and counts as in the first variant. The near-named input nest contains the entire state of the buffer; In addition to the contents of the data blocks to be buffered, this also includes the transient assignment between logical and physical addresses and the status of actuality. The buffer module itself becomes completely stateless.

For this to lead to good performance, it must provide almost very fast access. The idea is to optionally connect a device_ramdisk to this input, or any other relatively fast device; For example, when buffering accesses to extremely slow tape drives ⁷⁴ , this may also be a nest held on disk. Ultimately, buffer does nothing more than pass the temporal access behavior of the fast input to the output. The instance connected to the fast input is loaded with smaller amounts of data than the slow input; in the event of a shortage of storage, it may file storage recovery applications (see Chapter 5).

The explicit use of device_ramdisk as fast input has the further advantage that the problems of memory recovery, as well as the different transfer_size block sizes mixedly used in the overall system exclusively there to solve are.

by virtue of of foreseeable advances in hardware development is too expect future calculators have very different internal storage hierarchies than they usual today are. The building block concept allows a flexible adaptation to changed Conditions.

4.1.3 map_ *

Task of this type of block (see 14 ) is to transform a static nest into a dynamic one. There is therefore only one input (which usually only needs to implement single-user behavior ⁷⁵ ) and one output that should provide at least multi-user competence in the case of network operating systems; However, the creation of this competence can also be delegated to a downstream or internal adaptor _ * instance (see Section 4.1.8).

It Different types of map _ * blocks can be realized Doing their job with each other's internal implementation procedures solve and adapted to special load and usage models. As examples are now two possible Implementations described, map_simple and map_simple_delta.

The Transformation task is done specifically at map_simple as follows: it is assumed that the maximum sizes of the entrance and exit nest nearly are the same, and that the consumer at the output only requirements in block sizes, as stated by the MMU for the virtual memory management will be put (typically 4Kbyte or 8Kbyte). The transfer_size attribute of the starting nest is therefore set to such a block size. This means, that all operations, especially the move operation, only in multiples of this transfer size allowed to. Thus an efficient realization is already obvious: one use a table containing an illustration of the block numbers or addresses of initial nest on those of entrance nest realized. This table is of the order of magnitude by a factor of 1000 smaller than the size of the nest to be transformed, causes a space overhead of about one per thousand, the meaningfully pre-reserved at the beginning of the entrance nest. All operations calls to something with the virtual addresses too have to do (get and possibly lock / unlock) and arrive from the exit, be after translation passed through this table to the entrance through. The move operation is realized by a shift within the table, the for the reasons already described It costs about a factor of 1000 less than if you move through Lots of block transfer and copy operations in the static Entrance nest would have realized (which might, for example, get a building block named map_braindead). These Property can be to exploit to further reduce the effort: if you look at the table Once again realized in its own private nest, this in turn can managed using any other map _ * instance, which should only support the transfer_size granularity of the table elements (For example, map_simple_delta, map_braindead, or a combination from map_simple with a downstream adaptor_ *, which is in section 4.1.8 is described). At cheaper Choice and combination of building blocks to multi-stage cascades The costs, especially for very large nests again by a few Decrease powers of ten.

An address translation causes after prolonged operation with many move, clear and delete operations a phenomenon that is known in the literature on file systems as fragmentation (see eg [MJLF84, McK96]). This phenomenon describes the fact that a high locality of accesses on the output side of the map module is not necessarily translated into a high locality of accesses on the input side, since the table can throw the addresses together, much like hashed methods. However, a consumer expects read or write jobs given in contiguous and ascending address order to perform significantly better than random access ⁷⁶ . To solve this problem, several known methods are available which are analogously transferable from the literature via file systems, for example intelligent all-cation strategies and defragmentation runs. The background IO concept (Section 2.8.3) greatly facilitates in particular a defragmentation in the background of the ongoing operation, without noticeably disturbing the processing of the user activities. I expect that the application of very simple and primitive methods, such as the consistent creation of an Identity Map or "Near Identity Map ⁷⁷ ", will yield very good results if done background-IO in the background.

If one can assume that a defragmentation in the background ensures that the address translation deviates "only slightly" from an identity map, then it can also be realized in the following way, which I call map_simple_delta:
Instead of a fixed-size table, a list (or an array executed as a ring buffer or the like) of the previously executed operations that change something in the address assignments is used. As a result, the execution of move, clear and delete is extremely fast, because only one entry has to be made in the list, so that the result is a log of the operations to be performed (if all IO operations are also recorded in the log, a similar result is created) Effect as in log-structured file systems, see [R091]). The translation of an address can now basically be done in that in this log list to see if any operations have been entered that change something at a given address; These changes are then virtually virtualized in the correct order. Of course, this simple procedure only leads to acceptable performance if the list is kept as short as possible. One possibility for shortening the list is that those operations that cancel each other out in whole or in part or that can be replaced by a single replacement operation with the same semantics are removed from the list and possibly replaced by the replacement operation (Principle of compensation of operations). Another possibility, which is indispensable in practice in the long run, is the background shift and rearrangement by Background-IO, which makes entries in the list superfluous ⁷⁸ . It should also be noted that not only can map_simple_delta manage blocks with relatively high granularity as with disk devices or MMU pages, but also support smaller transfer_size values down to 1. The output automatically supports the same granularity as specified by the input, but it can happen that a get request with a high multiple of the transfer_size is only possible with a smaller multiple. This is explicitly provided for in the nests interface, and it is the responsibility of every consumer to deal with this case (although he can solve the problem by putting an adapter in front of him).

One map_ * - The building block must also have the operation get_meta as well as the operations implement on the meta-nest. A meta-nest should normally support a transfer_size of 1, which can be explained by internal use of an adaptor _ * block (Section 4.1.8).

It is also important that map_ * blocks should have the property of fall resistance. This term is intended to describe that any time separation of the block from its input or a loss of transfer operations (eg in the event of a sudden power failure, which leads to the loss of upstream volatile buffer information) must not destroy the integrity of the address translation. If you do not want to sacrifice the performance benefits of buffering in volatile memory, you have to live with the state on the persistent background medium constantly lagging behind the state in volatile memory, causing data and information to be lost on unexpected glitches. Known solutions to this problem ⁷⁹ are log-based writing methods; either in the form of separate logs or in the form of so-called log-structured memory. In order to support these procedures, the parameter depend was introduced in section 3.3.1, with which the sequence of write operations can be partially predefined. Crash resistance can also be implemented as part of ACID transactions if you already want to deploy them in a corresponding map_ * variant. Another possibility is the preconnection of a separate powersafe block analogous to [dJ93], which implements in isolated manner only the fall-resistance as a strategy and dispenses with the extension of static nests to dynamic ones.

The functionality from map_ * can be certainly with dozens of other methods for address translation which may have advantages with certain load characteristics can bring. These include, for example, trikes, balanced trees, B trees, fuzzy Hashing, and others. My remarks should have made it plausible that efficient realizations the concept of dynamic nests are possible.

4.1.4 selector

This adaptation module (see 15 ) cuts out a contiguous sub-address space from its input address space and makes it available at the output unchanged, with the addresses re-starting at 0 by default. If the cut-out address space is moved as a whole, then this does not affect the host address space, as well as the reverse of a move operation in the host address space over the entire cut-out area (transparency).

The Implementation is relatively simple, as well as a uniform address translation and check nothing and to do all the operations from the exit to the entrance can be served. It Two basic variants of selectors are possible, selector_persistent and selector_tmp, which differ in whether the clipping addresses are different and lengths as well as their changes persistently or not. In the former case Aid information is kept in the meta-nest of the entrance, with the the start address and the length relative to the guest address space is permanently held, so that a destruction of the selector with subsequent ultrapowering again gives the old state.

4.1.5 dir_ *

A building block of this kind (see 16 ) uses the entrance nest as a sort of collection container to form several independent exit nests. The output nests are recreated as needed by the building block-specific access operation create; previously created are re-instantiated by lookup, unless they are already instantiated. The different possible outgoing instances are distinguished by a search key, which is transferred as a contiguous data block. To query all existing persistently stored key values, there is a special exit called directory nest, which usually supports a transfer_size of 1, and of which read only. A directory nest represents a nest of seamless data packages, with each package containing exactly one of the existing search keys. The key values may or may not be sorted by any internal criterion. Deletion of key-values and their associated seed-nest instances can be accomplished as a building-block-specific operation and / or through a delete operation on the directory nest. Here, the methodology known from Unix is to be preferred, that a distinction should be made between static and dynamic references, and that an output and its memory space should not actually be released until there are no more dynamic references.

Out this description is likely have become clear that with it a directory can be realized, as in conventional operating system architectures of file systems to disposal is provided. However, a dir_ * does not provide a directory tree hierarchy to disposal, but resembles rather the flat index of a database. Nevertheless, directory tree hierarchies can be used very easy to make: at the output of a dir _ * instance just needs another you _ * instance to be connected and so on. In this way, the file system tree (or a currently instantiated Subtree of it) directly as a tree structure of block instances with the associated Wiring are shown. If one introduces the in section 4.2 Auto-instantiation of building blocks used, then you need As a user, it is not about the dynamic production of this tree structure take care of, because this happens automatically.

• • für jedes Verzeichnis individuell verschiedene Baustein-Typen einsetzen kann, beispielsweise dir_simple für kleine Verzeichnisse, dir_hash für solche mit besonders schneller lookup-Funktionalität, oder dir_btree für solche mit besonders guten Lokalitätseigenschaften trotz riesiger Ausdehnung
• • Datenkomprimierungs-, Datenverschlüsselungs- und sonstige Anpassungs-Bausteine wie adaptor_* und andere auf beliebigen Hierarchieebenen (automatisch) dazwischen schalten kann
• • auf Konzepte wie Mounts und Mount-Tabellen verzichten kann, da dies von einem redirect-Baustein übernommen werden kann
• • ebenso auf Konzepte wie Loopback-Devices verzichten kann, indem lediglich ein map_* zwischengeschaltet wird
• • nahtlose Integration mit der Funktionalität von Datenbanken möglich ist: dazu zählt nicht nur der später vorgestellte transaction-Baustein, sondern auch die Möglichkeit, spezialisierte Bausteine wie beispielsweise dir_fixed_keysize einzusetzen, bei denen eine Uniformität der Schlüssellängen zugunsten besserer Platzausnutzung erzwungen wird
• • eine virtuelle Herstellung von Verzeichnisinhalten durchführen kann, beispielsweise mit einem Baustein dir_proc für die Funktionalität von /proc-Dateisystemen, oder dir_join zur Herstellung der Funktionalität der aus der Datenbank-Welt bekannten Join-Operation aus dem Daten-Inhalt mehrerer anderer Nester. In diesem Fall können dir_*-Varianten entstehen, die gar keinen oder mehrere Eingänge besitzen, was sich u.U. mit dem althergebrachten Konzept eines Dateisystem-Baums nicht auf intuitive Weise modellieren läßt.

Compared to the functionality of classic file systems, this concept allows a much more flexible instantiation and wiring, because, for example

• • can use individually different block types for each directory, for example dir_simple for small directories, dir_hash for those with particularly fast lookup functionality, or dir_btree for those with particularly good locality properties despite their huge size
• • Automatically interpose data compression, data encryption, and other customization building blocks such as adaptor_ * and others at any hierarchy level
• • Can dispense with concepts such as mounts and mount tables, since this can be taken over by a redirect module
• • can also do without concepts such as loopback devices by just interposing a map_ *
• • Seamless integration with the functionality of databases is possible: this includes not only the transaction module presented later, but also the possibility of using specialized components such as dir_fixed_keysize, which enforce uniformity of key lengths in favor of better space utilization
• • make a virtual directory content creation, for example with a dir_proc building block for the / proc file system functionality, or dir_join to get the functionality of the database world known join operation from the data content of several other nests. In this case you can create _ * - variants that have no or more inputs, which may not be modeled in an intuitive way with the traditional concept of a file system tree.

• • die Index-Region,
• • die Meta-Region,
• • die Daten-Region.

I would like to explain the basic functionality of you _ * - building blocks using the example of a realization of dir_simple. A total of three different regions of contiguous address ranges are used to realize the container functionality. these are

• • the index region,
• • the meta region,
• • the data region.

These Regions become within the entrance nest and the entrance meta nest created, with the data region in any case in the entrance nest, the meta-region definitely in the input meta-nest, and the index region optionally in one of the two nests can (meaningfully should be the assignment of the size of the index dependent be made).

dir_simple considers each of these regions to be compactly contiguous subnodes, and uses the move operations available at the input to perform insertions and deletions of index values, as well as passing the move operations arriving at the outputs to, among others, the input. For the ge_ maxlen values of the outputs, this means that their sum must be less than or equal to the input's get_maxlen value ⁸⁰ . The internal implementation of dir_simple does not need to worry about the provisioning and moving of space, as this functionality is already available at the entrance. To fulfill the functionality of an instantiated output (with the exception of set_maxlen, which must be intercepted), internal instances of selector can be used.

The Order of entries is the same for dir_simple in all regions: for example an entry in the index region at the very beginning at the first position added becomes, then becomes in the Meta region and in the data region likewise procedure and there created each place in the address space. In this Fall, or if, for example, the size of a starting nest through set_maxlen changes so much that overlaps threaten, the entire remaining address space is moved in one go; because of the transparency property of internally used selector building blocks the already instantiated outputs do not notice this.

Of the Index area is stored directly in dir_simple in the same format, as requested by the directory nest exit. Other you _ * types can Of course deviate from it. The exits a _ _ _ building block should at least provide multiuser competence. Therefor There are several possibilities: the internal realization could e.g. only by single-user behavior done (what the draft small little simplified) and the multiuser competence at the outputs through an adaptor _ * instance is available put. For However, the application areas of network operating systems is continuous multiuser behavior advantageous. This is relative to dir_simple easy to fulfill, because the implementation described above is largely stateless can. For stateless implementations, the addition of multiuser or multiversion behavior simply because only all of them potentially conflictual Operations are to be clung by lock / unlock pairs. The only conflictual Operation at the exit nests is set_maxlen, which is reasonable Design should rarely be called; all other operations except Modifications in the index region do not need additional Braces and run unchanged or only slightly changed by.

These quite simple realization has very good locality characteristics: the locality behavior an exit is passed on directly to the container at the entrance. If small directories are so implemented that the index region lies in the meta-nest of the entrance, then contains the meta-nest in the case of recursive nested directories at the root of the entire tree of all the indices, which are some of them compared to the sum of all file sizes orders of magnitude smaller fails (at least at usual through human users caused file sizes) and solely because of this low locality the extension allows quick access (where caching the transitive upstream buffer module separate concepts how inode or name caches make superfluous).

The Assignment of the index region to one of the two input nests is a strategy decision that is made differently in each individual case can be; very big Index Regions can also be moved to the regular Inbox Nest, so the locality the meta-nest as possible little is worsened.

A further strategic decision-making possibility for the locality behavior is to merge some or all of the regions together. This can be especially true in the amalgamation of the index with the meta-region Benefit provided that the metadata of the outputs take up very little space. The efficient access to the propagated by Hans Reiser in reiserfs very small file sizes (like e.g. when modeling individual fields of data records Database with the help of "mini-files") can be possibly by merging index and data region, or by a case by case dynamic heuristic assignment to a of the regions. Furthermore one can use the representation of the fields of data records Database a functionality-strong restricted Block type dir_record, which always has the same index structure Records of the same structure and the same metadata (in which the field names and field lengths and other attributes stored) not in the index region of each instance stores, but by reference from a common external Source, and thus only a negligible overhead overhead every single instance causes.

These examples should have made it plausible that special requirements that were previously often an incentive to develop complex and extensive file systems with tricky internal implemen served by a building block concept can be at least as well covered. The block decomposition presented here distributes the problems and functionalities occurring in file systems over several types of blocks, isolating them from each other and enabling previously unknown combinations. Some of the possibilities are solved in a simpler way than with stackable file systems (see [HP94, HP95]), since no distinction is made between different levels such as "files" versus "file system trees".

4.1.6 union

This module (see 17 ) is in some ways an inverse operation to selector or dir_ *: multiple input nests appear in a seed nest and are lined up side by side in terms of addresses. Parameter or meta-information is used to determine whether an input address space is to be completely connected to its predecessor (so that any gaps at the end of the predecessor and at the beginning of one's nest are pushed together and move operations of the predecessor are performed). Whether the connection should be made via get_maxlen, or whether it should possibly be "pinned" at fixed addresses (similar to selector).

On the later discussed mechanism of generic operations can be inputs at runtime and remove.

One important application of union is the compilation of different Regions or "segments" in virtual address spaces or. Protection areas, such as the classification into code, stack and Data segments, as well as in mappings of other nests. Different mapping types can be achieved by preceding adaptation modules such as cow (Section 4.1.10).

4.1.7 mmu_ *

This module (see 18 ) has exactly one input and no output ⁸¹ , so in terms of the wiring logic is a pure consumer. It represents the interface to the memory management unit (MMU) of the computer hardware. The nest is in this case 1: 1 ^{82 converted} into a virtual address space, which can be addressed via control flows directly by machine commands of the processor.

The realization of this module is relatively simple compared to conventional implementations:
if a page fault occurs, the affected data block is requested by get and subsequent transfer in read mode from the input nest and entered into the page tables ^{83 of} the MMU. In the case of an ejection, put is called, in the case of changed pages before that, also transfer is called in write mode with a low background IO priority.

Through the notify_ * interface discussed later, mmu_ * receives knowledge of physical data blocks intended for clearance by the memory management, as well as of address areas which have become invalid, for example by means of move operations, and carries them out as just discussed ⁸⁴ . On this they can possibly be requested again at the next page error, but this has relatively low delays result, if the page is in fact still in the central LRU cache of the transitive upstream buffer instance. Such recoveries can therefore be triggered on suspicion and at any time by the storage manager at a central location ⁸⁵ without significantly disturbing the activities of a user process. This results in a continuous age determination within the working sets (compare [Den68, Den71]) of all existing virtual address spaces, which is similar to the effect of the known second-chance algorithm for page replacement. As a side effect, changed pages are swapped early on suspicion with background priority ⁸⁶ , so that there is a chance for a later actually occurring memory shortage; meanwhile the site has not been modified again and therefore can be recycled immediately, without having to wait for the completion of IO.

In a mmu_ * building block, no special paging strategy of any kind with different modes and dependencies of mapping types is needed, which is the lion's share of complexity in conventional implementations. These tasks, including the persistence of private mapping segments, are handled by upstream building blocks ⁸⁷ .

For a mmu_ * block to be at the end of a block hierarchy, the usual separation into spinlocks and scheduling locks must be removed (see [K ⁺ 91, LA93] and section 3.3.5). This is necessary in Symmetric MultiProcessing (SMP) machines to distribute multiple mmu_ * instances to different processors or to run multiple control streams distributed to different processors on the same mmu_ * instance. It is also required that page fault interrupts may call the nest operations (see [KE95] and section 3.3.5). The realization of protection areas is also the task of mmu_ *. This requires a link to the control flow implementation, which is best solved outside of the regular device wiring, since it is independent of it (this also applies to the connection to the interruptions) ⁸⁸ . Different protection areas can be implemented most easily by assigning different mandates (see section 2.7) and different treatment in lower check _ * instances. With this, mmu_ * instances become administrators of those mandates that have to do with the protection areas.

4.1.8 adapter_ *

Please refer 19 , It is an adaptation building block with only one input and one output, which mediates and translates between nests with different competencies and behaviors such as different transfer_size attribute values.

• 1. Der Ausgang hat zu geringe Kompetenzen, um die Anforderungen durch das Verhalten der Eingänge abdecken zu können.
• 2. Ein Eingang unterstützt nur singleuser-Verhalten und verträgt sich daher nicht mit anderen Eingängen.

Adaptation between different access models As can be seen from Table 6 on page 133, there are the following cases in which it is not possible to connect inputs to the outputs of other blocks:

• 1. The output has too little competence to cover the requirements by the behavior of the inputs.
• 2. An input only supports single-user behavior and is therefore incompatible with other inputs.

For each of these cases I suggest to introduce an adapter type that addresses the particular problem solves. case 1 leaves For example, by adaptor_multi solve that at the entrance not implemented after existing lock operations. For the production dermultiuser competence need only pass the rest of the operations to become. Somewhat more elaborate is the production of multiversion competence, because in this mode of each physical data block potentially several Versions need to be brought into play and managed. In In this case, it makes sense to have another tmp or fast input analogous to buffer or cow (see section 4.1.10) the additional Contains versions and related status information.

to solution In case 2, I propose a module adaptor_synchronize introduce. This can be an input with multiuser or multiversion behavior assuming that this functionality is provided by adaptor_multi can be provided. Because at each exit always only one Consumers with singleuser behavior may be connected, must adaptor_synchronize correspondingly many outputs have to be subsequently instantiated or deleted at runtime have to.

The problem with adaptor_synchronize is that every output has the illusion that it is the only consumer of a Nest instance that makes changes. Such an illusion is also generated by classical database transactions. In principle, the block transaction (Section 4.1.11) is also suitable for producing this illusion. From the transaction theory is known that a complete isolation of the participants in any unpredictable and really parallel actions of different single user participants is not possible without the risk of deadlocks or rollbacks in purchasing. Therefore, I propose a distribution of functionality: true parallelism is to be enabled by transaction; a limited and easier-to-implement form of the illusion of single-user behavior is provided by adaptor_synchronize. This happens as follows:
We assume that consumers work stateless at the exits, ie they request data blocks using get only for a relatively limited period of time and release them as soon as possible using put. In complete statelessness one can count on the fact that each consumer will soon release all its blocks again, or that at least a complete recovery through notify _ * - operations (see chapter 5) is possible. Under this condition, a simple strategy can be implemented by locks by having only one output at a time accessing the status of the input; the others have to wait until they have returned all their status. As soon as any requests arrive through another exit while any status is already taken, then the adaptor_synchronize implementation tries to get the otherwise assigned status back as soon as possible using notify_ * ⁸⁹ . This unfortunately limits the parallelism very strong one, but it is easy to implement, avoids deadlock and does not need a rollback operations parallel in real transactions and not previously known access behavior are unavoidable ^90th

The implication of this misery is, in my opinion, that one should avoid the single-user programming model and provide consumers with explicit multiuser or multiversion behavior ⁹¹ (Chapter 7) whenever possible (assuming parallelism, scalability, and performance puts) ⁹² . In this sense, adaptor_synchronize should only be understood and used as a makeshift solution.

adaptation between different transfer_size values ideally should Building block implementations do not have to worry about the problem that the transfer_size of an output match that of an input got to. This conversion task should be delegable to adaptor_ *.

• 1. Hochtransformation von einer kleinen transfer_size am Eingang zu einer größeren am Ausgang
• 2. Hinuntertransformation von einer großen transfer_size am Eingang zu einer kleineren am Ausgang

In general, it may happen that the involved transfer sizes do not form divisors of each other. This case hardly appears in practice because, for good reasons, only powers of two ^{93 are used} as fixed transfer quantities. If it should nevertheless occur ⁹⁴ , one can manage in the following way: one determines the gcd (largest common divisor) of the two occurring transfer sizes. Then switch two adaptor_ * instances in succession, the first of which transforms from the input transfer size down to the gcd, the second from the gcd to the output size. In the following, I restrict myself to the assumption that one of the two transfer quantities represents a multiple of the others. There are two cases:

• 1. Up-transform from a small transfer_size at the entrance to a larger one at the exit
• 2. Down transformation from a large transfer_size at the entrance to a smaller one at the exit

at The transformation is the problem that the consumer is facing its input and thus also at the output of the adaptor_ * expected that a get operation is a physically contiguous block of data with at least its transfer size. Because at the entrance of the adaptor_ * set a smaller transfer size is, the attached producer does not necessarily need data blocks this size and / or not necessarily at appropriately aligned address limits in to supply physical memory (however, every producer advised to fulfill this if it is in an individual case without major costs possible is).

In general, it is desirable for the input to be able to participate in multiuser or multiversion behavior, allowing more concurrent consumers to independently request and hold blocks using get. In this case, shifting blocks in main memory to "cheaper" physical addresses is generally out of the question ^95. If you do not want to operate the input in single-user mode, then there is nothing left but to make physical copies of data blocks ,

A A physical copy made by an adapter_ * must also be from this Module with respect the reference counter, Memory release, etc. are managed; at the last put on one For copying shared copy the changes must be made to the original or be transferred back to the smaller original parts.

at closer consideration of the problem is striking that the production of physical copies may hold the chance of possible parallelism of operations thereby increasing that the different versions are expressly for a multiversion model on Output can be used even if the input only multiuser behavior passes. It may be appropriate to use the functionality of adaptor_multi right here to integrate, or adapter multi_gleich with the High transformation capability equip so that a single block type does both tasks. For the down transformation: here is the problem of transfer size differences not, as a smaller divisible transfer size the conditions the larger one already from self fulfilled. When passing physical addresses to the output is only to note that these may be within a block, the delivered from the entrance. When returning by means of put a must such physical address back to the transfer_size of the input to be normalized, what by division and multiplication, at Power of two can also be done by masking out address bits.

The Downward transformation, however, has to contend with a problem that does not exist in the high transformation, because it already there for symmetry reasons fulfilled by itself is: the move, clear and delete operations can be done by the consumer at the exit to be requested in smaller portions than they are from the producer available at the entrance be put. Therefore, a simple submission of these operations unfortunately not possible to the producer in the general case.

To solve this problem, an adaptor_ * could completely redeploy the move operation, without making use of the fact that the entrance already provides a dynamic nest. However, this would contradict the goal of using the building blocks for the "most orthogonal" decomposition of tasks occurring in operating systems, but what does "orthogonal" mean? For the evaluation of the orthogonality and homogeneity of a building block behavior, I see as an important criterion whether a transformation can be reversed again by a retrograde transformation, or at least can be reversed to a constant remainder (principle of compensability). This would mean that a down transformation with a downstream high transformation to the original transfer_size should not change the content of a nest, so overall it should represent an idempotent mapping.

Unfortunately, this is not possible in perfect pure form for information-theoretical reasons: In order to manage the distribution of a given fixed number of payload bytes to a likewise fixed, larger address space with holes, space must be used somewhere for the representation of this status information. If you distribute the useful content on the larger address space somehow (eg randomly in a kind of Swiss cheese), then there are more possibilities for the number of such possible distributions, the smaller the transfer_size is chosen (the Swiss cheese may figuratively ever smaller holes and also contain more holes although it does not change its weight or volume). Which of these increased possibilities actually exists must be noted and stored somewhere, which, for information-theoretical reasons, results in a need for space that increases with ever smaller transfer_size, at least in the worst case ⁹⁶ . It follows that in general it is not possible to transform the transfer_size down without any additional space being consumed for storing the now finer imaging possibilities for the domain of definition of the nest.

However, this does not mean that extra space needs to be consumed in all cases. I can request the following desirable property from a down transformation:
If only those operations are performed at the output of the down transformation that could take place without the down conversion because they (coincidentally) already satisfy the conditions of the larger transfer_size at the input, then the same nest condition should be visible at the output of the down transformation Down transformation not available. This means, among other things, that in this case no space for internal administrative information may be zwzwackt (the facts as such can be noted in the meta-nest with low space costs). Such subthreshold, in a sense, provides refinement of the input nest at the output.

Such a refinement is in principle realized by the fact that only the differences to the coarser input structure are managed internally. Among other things, this problem is compounded by the problem of internal blending known in the literature, for which there are several possible solutions ⁹⁷ . I do not want to go into further details in this work.

4.1.9 redirect

This module (see 20 ) realizes the functionality of hard and soft links ⁹⁸ , as well as mount points and tables. It has two inputs and one output. By default, the first input queries the meta-nest (if it should be empty, including the data-nest) if it contains a path in the auto-instantiation network. The second input is then automatically connected to the specified (possibly still to be constructed) output, which in turn is then available at the output unchanged. Further details are explained in section 4.2.

4.1.10 cow

This module (see 21 ) implements the copy-on-write strategy known from conventional private mappings. It has two inputs labeled orig and tmp, and one called merged output.

in the initial state, the input nest labeled tmp is empty, and the exit marked merged will appear exactly the same Nest state as at orig entrance. The task is in isolation the orig input of all changes, which are commissioned by the consumer behind at the merged exit. Any changes at the nest contents of the output or at its address space must exclusively in the tmp nest be registered and buffered so they do not actual changes effect at the orig entrance.

The implementation of write-transfer operations or get in the write mode is relatively simple and follows the known methodology, whereby holes in the domain of tmp are directly exploitable. More difficult is the provision of move operations. An analysis of this subproblem shows that it has a strong relationship with the address shifting problem in the map building blocks. One possible implementation is therefore the internal use of a map module, which however should be able to handle holes in the orig nest correctly.

4.1.11 transaction

in the Difference to databases where transaction identifiers (TIDs) mostly are firmly linked to processes, Under a transaction I understand a logical view of one Dataset containing the well-known ACID property (or properties other transactional paradigms), and those of any number of processes cooperative (or, if additional locks are used, also in multiuser or multiversion model). Solidified by the task In particular, mappings between processes and data spaces will also be allows that a process participates in several transactions, also in parallel may. The default scenario of a fixed 1: 1 mapping between Processes and data spaces is included as a special case in this model.

Sequential transactions

A cow building block (see 21 ) already realizes an important part of the known isolation functionality of transactions (see 22 ): To simulate a rollback operation, all you have to do is forget the contents of the tmp nest and set the merged output back to the initial state of the orig input. A transaction module can be realized in principle as a slightly modified cow block, which inherits its basic operation of cow.

In principle, the commit operation can be accomplished by simply doing nothing: stopping changes to the merged output, and viewing its state as "frozen." Such a "frozen" nest now serves as a starting point for one temporal successive (non-parallel) transaction whose orig input is merged with the merged output of the most recent successfully completed transaction, ultimately creating long chains representing all the historical intermediate steps of the states of the nest triggered by the transaction operations , The output of the last successfully completed transaction instance of a chain is called the actual version. For the time being, only a single, incomplete transaction may be added after the current version; otherwise divergent version splits ^{99 could} emerge that contradict the concept of a unified logical view.

It It is clear that such chains can not be arbitrarily long. The Removal of building blocks without change The semantics is possible in the following way: a completed Transaction may execute internal operations without further invariant from the outside through the (opposite cow newly added) operation to be initiated and cause the starting nest to continue to be viewed from the outside retains the same frozen state while the contents of the tmp input is integrated into the orig entrance nest, so the tmp nest always gets smaller until it finally completely becomes empty. In this integration operation, the contents of the orig input so changed that he finally matches the frozen merged output; that is the Isolation lifted. From now on you can now completely stateless remove the transaction block from the chain, without Side effects arise.

Parallel transactions

With The methodology just presented can only be done in a sequential manner modeling successive transactions.

To create true parallelism between multiple transaction instances, they must be attached to the same update version (unless they intentionally start with an outdated state); please refer 23 , If this were done with separate individual building blocks for each transaction, then the different transaction views would have to keep up to date via this or another connection point, each tracking the current status at their entrance, which in principle would be possible but would cause a multiplication of always similar operations to multiple locations ¹⁰⁰ . To save this effort, it is better to have a conventional implementation of transactions (see eg [GR93]), possibly also of different transaction Mo packaging (see, for example, [Elmbe]) into a building block that uses an internal central buffer to manage all the existing versions, and / or whose input works in multiversion mode (but then the rest of the infrastructure must also be present).

at The combination of transactions with protection areas can be the building block concept with functionalities come up in conventional operating system implementations would cause a considerable effort. An example is this Exception handling in conventional runtime environments. This can only react to a mistake, but usually do not fix it, since it is already "too late" when the error occurs. Transactions offer the possibility on earlier conditions of address spaces reset and to try again, even on whole collections and configurations of address spaces (speculative execution).

Very interesting also the combination of transaction blocks with the following block types which enable distributed systems in networks, depending on the job site at different levels of a building block hierarchy.

4.1.12 remote

This module (see 24 ) implements the client-server paradigm. A nest is made available on another machine so that its properties are indistinguishable from a local nest.

The Realization of the network protocol can be stateless, if you add a buffer instance that caches the buffer Traffic over the internal network connection is reduced in many cases and incidentally lowers the latency of many operations. In a stateless realization holds the Client part no status information about the state of the nest but must pass each and every operation to the server. this leads to to a high simplicity, robustness, independence and fall protection.

ask burglary security in networks, encryption, authentication etc. are an internal matter of the building block implementation; This work will not be discussed further here.

4.1.13 mirror

This module (see 25 ) implements the concept of Distributed Shared Memory.

A The building block instance of mirror is allowed to be physically separated over several Extend computers that communicate with each other via internal (not visible from the outside) Communication mechanisms (this provides especially group communication). The distribution of the block instance over several Calculator is indicated in the picture by dashed lines. One- and outputs are present in pairs in the same number in the basic model. The exits provide the same functionality as they are in a non-distributed system of the common Wiring of several inputs is fulfilled at the same exit: everywhere prevails the same logical view, the nest is logically identical and allows Cooperation in the multiuser or multiversion model.

This concise but complete functional description allows many possibilities for implementation, which can essentially follow the known techniques of the literature (see eg [TSF90, Doe96, Esk96]). What the inputs contain can vary greatly with different mirror _ * types. I'll briefly explain two extreme cases:
In a realization called mirror_replicate, all inputs contain the same nest state as the outputs. Any change arriving at any output is immediately passed through to all inputs of all distributed sub-instances. With parallel access to multiple machines this usually requires distributed internal synchronization operations to maintain consistency at all times.

The This causes relatively high latency problems by runter-local downstream of each buffer instance behind the exits in many cases mitigate; therefore, the internal realization of the communication protocols largely stateless.

Another implementation called mirror_primarycopy has only a single input, the one is permanently assigned to the computer and always remains there, even if other outputs are dynamically added or removed on other computers.

Finally, I want still on hybrid forms between the two extremes of complete replication all data and the replication-free primary copy. These include building block variants, their entrances not for Replicas, but for to use the provision of the sum of all available space (disjoint distributed memory). It is possible in principle, one Building block mirror_general that covers both the extreme cases of complete Replication as well as the primary copy, as well as any mixed forms with partial replication, as well Covering mixed forms with disjointly distributed memory.

It should also be mentioned that the RAID concepts (Redundant Array of Inexpensible Disks, see [CLG ⁺ 93]) can be considered a special case of mirror with a special kind of redundancy distribution according to the RAID level: it only goes on a distribution of inputs and outputs on different computers omitted. An efficient realization of mirror should therefore strive to ensure that local replication does not result in noticeable overhead. This would also make it suitable for the task areas in which software RAID has been used so far.

implementations by mirror should definitely have the basic ideas of reliability pay close attention and, for example, with the case of network partitioning (see [DGMS85]) can handle sense. A detailed treatment these concepts would go beyond the scope of this work. It would be interesting to find out to what extent the building block concept and some of the here. presented building blocks in the internal realization of mirror can bring benefits.

Finally, it should be mentioned that the functionality of process migration (see [Smi88]) can be represented as a special case of distributed control flows on distributed shared protection areas or by switching of confor- mity flows to other computers using mirrored protection areas. This requires that the mmu_ * devices used implement multiuser behavior ¹⁰¹ .

The Distribution of nests is also common for making distributed namespaces very helpful; mirror is thus the essential basis for a distributed operating system.

4.1.14 pipe

To understand the pipe design (see 26 ) It is important to remember that a line represents a hierarchical relationship between block instances and has nothing directly to do with data flow directions. In an abstract perspective, therefore, the participants in a pipe are in principle equal, they are therefore connected to different outputs. The internal status of a pipe instance is kept in a tmp input, to which not only device_ramdisk can be connected, but also buffer nests, for example, which would not fit into the main memory of a minicomputer.

4.2 Instantiation of building blocks

• 1. Der eigentliche Instantiierungs-Mechanismus (technische Durchführung der Instantiierung)
• 2. Die logische Kontrolle, welche Instantiierung zu welchem Zeitpunkt und aus welchem Anlass ausgeführt werden soll

To instantiate the building blocks, some mechanism is needed. This should be outside or above the actual building block hierarchy because it is a higher-level control mechanism. Following the principle of separation into mechanisms and strategies, the following subareas should be used:

• 1. The actual instantiation mechanism (technical implementation of instantiation)
• 2. The logical control of what instantiation should be performed at what time and for what reason

These Separation has the advantage that, in particular for point 2 several different Be used simultaneously or concurrently.

4.2.1 The mechanism

For the technical implementation of the instantiation, I propose to use a block called control, of which there can be any number of instances on each computer, but in the normal case an instance is sufficient, which in turn must have been instantiated at the start in a way outside of the normal instantiation mechanism (and, logically, it must be ¹⁰² ). The control block (see 27 ) manages all block instances that it generates, including wiring. He needs himself I also propose to logically separate these two functional areas: The block instances managed by a control instance can generally be located in another (virtual) address space (which in turn can be divided into protection areas) as the control instance itself; Thus, for example, any hierarchical nesting of address spaces or entire virtual machines is possible ¹⁰³ . The controlling control instance uses the tmp input to hold all necessary status in it, and provides a "process image" or a set of protection areas at the image output that can be used in a subsequent (possibly via intermediate blocks such as union) or mmu_i386 or mmu_dummy instance, to allow for separation between the address space hosting the control instance and the address space in which the managed instances are to run. Explode portions of an operating system into "user" address spaces. In this way, users can create independent subsystems that are similar in functionality to virtual operating systems. This blurs the classic division into core and user responsibilities; the distribution of these responsibilities is just a matter of configuration. However, separating the control instance and its image into separate address spaces is not a requirement. ¹⁰⁴ : If you insert the image output in the same mmu_ * instance where the control module is located, you can easily Address space strategies ¹⁰⁵ drive. As a further special case, it is also possible in principle for a control block to manage itself ¹⁰⁶ ; in this case, there is no difference between "inside" and "outside"; destroying the control instance would then not only result in the destruction of all managed instances, but would never allow another re-construction (this may exceptionally be desirable when shutting down the machine).

The commands for instantiating / de-instantiating the managed instances and for wiring are given via the control output. One possibility is the introduction of further elementary operations, or the use of the interface of generic operations (Chapter 6). Since only control operations are used on this line, it is shown in dashed lines. Furthermore, the attributes of the instantiated blocks, inputs and outputs and the wiring structure can be queried via the control output. Clients for these operations can be any building blocks; iA these may also be in image ¹⁰⁷ . For purposes of external communication, there are a dynamic number of inputs and outputs in * and out * ¹⁰⁸ which serve as interfaces for LRPC and which can be used for any purpose ¹⁰⁹ .

It makes sense to instantiate / de-instantiate from constructing / destroying disconnect: When instantiating is only room for the device infrastructure (e.g., static attributes) and allows for wiring. The parameterization of the block instance (for example, setting dynamic Attributes) takes place at the latest while constructing. If one only destroys a building block, but not de-instantiated, in the end it only becomes the state the statelessness switched (that is, after the completion of all possibly. still existing orders the possibly existing internal status is passed on to the inputs, afterwards no operations are processed), and he can then be put back into operation by design.

Details on the internal realization of control are not dealt with in this work; the basic functionality is only sketched here:
In the code input, dynamically linkable machine code is kept ready for all instantiable block types ¹¹⁰ . When first used, it is copied to tmp and linked. The instances of the managed blocks are generated in two phases: The memory requirements for an instance are read out of the static attributes of the block type to be instantiated, and corresponding memory space is reserved in tmp. Subsequently, an instantiation routine is called; this can carry out further actions if necessary ¹¹¹ . After instantiation, the wiring should normally take place; It is already possible to check for conflicts between static competence attributes and behavioral attributes. The construction also takes place by calling a block-specific routine with suitable parameters. Since dynamic attributes may only be set at this point in time, the design may fail. Destruction and de-instantiation work analogously.

4.2.2 Some possible basic strategies

• 1. Manche Baustein-Arten wie z.B. dir_* können nur an bestimmten vorgegebenen oder vorgebbaren Stellen einer Baustein-Hierachie instantiiert werden, weil sie einen Interpreter für ein bestimmtes konkretes Datenformat darstellen. Es macht i.a. keinen Sinn, andere Baustein-Arten als die für die jeweilige Interpretation geeigneten zu instantiieren; häufig existiert für ein bestimmtes Datenformat nur eine einzige Interpreter-Baustein-Art (in einem gewachsenen System allerdings oft in verschiedenen Versionen, von denen bei der Instantiierung die geeignete ausgewählt werden muss).
• 2. Andere Baustein-Arten wie z.B. mmu_* oder geschachtelte control-Instanzen werden fast ausschließlich auf Veranlassung von Benutzer-Aktivitäten instantiiert.
• 3. Es gibt Mischformen zwischen beiden Extremen: ein Verzeichnis-Pfadname wird zwar vom Benutzer vorgegeben, die Art des jeweils zu inantiierenden Bausteins hängt jedoch vom Datenformat ab.
• 4. In manchen Fällen können Instantiierungen oder Re-Instantiierungen auch ohne konkreten äußeren Anlass geschehen, z.B. zeitgesteuert in selbsttätig optimierenden Betriebssystemen (vgl. [BR76]) oder zur Erzielung von Fehlertoleranz und Ausfallsicherheit.

There are several possible scenarios for an instantiation event:

• 1. Some types of building blocks, such as dir_ *, can only be instantiated at certain predefined or predefinable locations of a building block hierarchy because they represent an interpreter for a particular concrete data format. In general, it makes no sense to instantiate other types of building blocks other than those suitable for the respective interpretation; Often, there is only one single interpreter for a given data format ter block type (in a grown system, however, often in different versions, of which the appropriate one must be selected during the instantiation).
• 2. Other types of devices, such as mmu_ * or nested control instances, are instantiated almost exclusively at the behest of user activities.
• 3. There are hybrids between both extremes: although a directory path name is specified by the user, the type of block to be instantiated depends on the data format.
• 4. In some cases, instantiation or re-instantiation can also be done without specific external cause, eg time-controlled in self-optimizing operating systems (see [BR76]) or to achieve fault tolerance and reliability.

Of the Case 1 can be either deal directly in control, or by a separate block type registrar, who is a registrar for different data formats are used. Data formats should preferably in the associated Meta-nest can be described; but there are also special cases like Disk partitions or you _ * - blocks for conventional archive file Formats (such as .tar or .zip), where the format detection by Inspection of the contents of the relevant nest. One Registrar also manages the methods for automatic format detection.

In order to achieve the greatest possible flexibility with different triggers of instantiations, I propose the establishment of strategy _ * building blocks; please refer 28 , These control the control or registrar module and receive information about existing data formats and competences from there; they are themselves controlled by other control instances, such as user operations or other strategy _ * instances. In the picture, the control lines are shown in dashed lines.

One Example would be a building block strategy_asciipath, the path name in ASCII encoding accepted and indirectly over register or control on a directory tree of you _ * - instances maps. Another building block strategy_utf_ascii could be interposed, to translate path components in Unicode or UTF-8 encoding to ASCII and UTF-8 special characters into a reversibly unique equivalent multi-character ASCII representation transferred to. Another example would be strategy_ascii_bin, the binary encoded number keys (e.g., field key in databases) from equivalent ASCII representations generated. Other strategies could be used e.g. the administration of Take over URLs; The extensibility and flexibility are provided by this architecture barely set any limits. To constantly repetitive instantiations / de-instantiations of building blocks strategy_cache can create a "store" of frequently used instances, which in case of non-use may only be switched to "stateless" The functionality of the classic fork system call from Unix also by strategy _ * - building blocks, those of / proc file systems through specialized types of registrars that are automatic Default instantiations of registered components provide. The problem of incompatible competencies and behavior of attempted building block wirings or constructions can be through an intermediary registrar_intermediate. This knows all kinds of things adaptor_ * and other conversion block types including their properties and causes the automatic interposition of the suitable components. On similar Way can be Network transparency through automated interposition of achieve remotely.

at Implementation of appropriate strategies (e.g., [LS94]) can be achieved Fault tolerance through automatic re-instantiation of failed ones Achieve building blocks, or in combination with network transparency to use for dynamic load balancing. There are countless others Applications for strategy_ * and registrar_ * conceivable.

For database designers could be a delightful task to develop a building block strategy_sgl, which is suitable for a suitable design not only for the classic applications in databases ¹¹² , but extends the principle of separation of logical and physical access path to such applications, the hitherto considered to be the domain of operating systems ¹¹³ or distributed systems (in particular the management of virtual user address spaces ¹¹⁴ ).

5 callbacks through notify operations

hierarchical Press relationships a dependency ratio. Building block instances that are "higher" in a hierarchy have "power" or "control" over those below stand. The building block model lines express such hierarchy relationships out.

However, there are cases in which a clear hierarchy can not always be pure-bred. Operating system designers traditionally try to avoid such cases as much as possible. Ideally, an operating system should be writable through a layered model (see [Dij71]). The notify operations are meant to be able to maintain a layered model even if it would jam for some reason (see [Cla85]). In this view, notify operations are exceptional and should not be abused. I will try to justify those use cases where I see benefits through the use of notify operations.

5.1 Ownership and ownership

The terms property and possession come from the legal system. There they mark the scope of a right: who owns a thing, has more rights than the owner. In particular, it is possible to rent or rent things; while you remain owner, although the owner (short term) changes. The new owner may transfer transitive ownership of one thing or partial thing to one or more sub-owners; they owe the return to the chief owner, that is the one from whom they received the sub-possession; this in turn owes the return of ownership to the owner. The owner is someone who owes nobody the return of the property ¹¹⁵ . In real life, such legal relationships occur, for example, when renting and subletting residential property. For example, a tenant of a 5-room apartment can sublet each room individually to students.

These Analogy would like I to the representation of the circumstances use in an operating system; Here I will be an example take ownership and ownership of data blocks and locks; these Methodology is also transferable to other objects.

Property and ownership are of a hierarchy regardless ¹¹⁶ and can change dynamically at runtime. A building block hierarchy divides the overall responsibility of an operating system into static responsibilities; when transferring a property, however, the temporary responsibility for the objects to be managed within the hierarchy is passed on.

For physical data blocks there is a natural form of ownership: this is the one instance that defines the physical address and managed, for example by the data block "created", that brings into existence ¹¹⁷ As a rule, this natural owner of the data block forth to him. subsequently to "lend", ie to assign the right of access or ownership to another entity for a certain period of time. The new owner can be hierarchically lower or higher. Regardless of the hierarchy, however, he eventually has to return ownership to the owner, otherwise the well-known problem of scarcity of resources due to no longer recyclable resources threatens.

29 shows a part of a scenario of a computer that is equipped with MMU hardware. In principle, the owner or main owner of data blocks can be any of the building block types involved. However, there are advantages if the address assignment of the physical data blocks is separated from the address assignment in the respective logical address space. For the logical addresses, there is a necessary owner or main owner, who must be able to determine at least the basic features: this is the user, who sits at the very back end consumer and wants to determine what the computer and the operating system should do for him; While he can delegate some of these tasks to the compiler or the runtime system (user heap management), he is ultimately the master of his virtual address space.

• • Verschiedene mmu-Instanzen greifen häufig auf dieselben Datenblöcke zu; beispielsweise gemeinsamer Maschinencode. Wenn das Eigentumsrecht bei der buf fer-Instanz liegt, ist die gemeinsame Nutzung von Datenblöcken relativ einfach zu realisieren. Billigt man das Eigentum dagegen den mmu-Instanzen zu, dann findet entweder keine gemeinsame Nutzung statt, oder diese muss wesentlich aufwendiger z.B. über ein Cache-Kohärenz-Protokoll hergestellt werden, das sich über die gesamte Hierarchie hinweg erstrecken kann.
• • Die Gefahr von Deadlocks ist leichter vermeidbar, da eine zentrale Instanz besser die Übersicht über die vergebenen Ressourcen wie Locks behalten kann.

In principle, physical addresses can be managed both at the top of the mmu_ * instances and at the very bottom of the buf fer instance or the possibly upstream device mem instance. In the presence of MMU hardware, however, it is advantageous to transfer the management of physical addresses and thus the ownership of the buf fer or device mem instance and not the many mmu instances for several reasons:

• • Different mmu instances often access the same data blocks; for example, common machine code. Having ownership of the buf fer instance makes it easy to share blocks of data. On the other hand, if the property is approved for the mmu instances, then either no sharing takes place, or it must be produced much more expensively, for example via a cache coherence protocol, which can extend over the entire hierarchy.
• • The danger of deadlocks is easier to avoid, because a central authority can better keep track of the allocated resources such as locks.

In the following example ( 30 ) there is no MMU hardware. The management of the physical data block addresses must be done (!) Because of the necessary match of logical and physical addresses with the mmu_dummy instances, which are a replacement for the missing MMU hardware. If no MMU exists, then independent translation from logical addresses to physical addresses is not possible; the only solution is to equate the physical addresses with the logical addresses. Therefore, it is better to maintain ownership of at least those data blocks used in process images at the top of the hierarchy at mmu_dummy or process_manager (otherwise, transformations could not be performed by intervening dir_ * instances or additional performance-eating copies be created ¹¹⁸ ).

These discussion should have made aware of ownership and ownership in principle independent of hierarchy relationships, and that is a well thought-out assignment Can save implementation effort and performance.

• • Ein Eigentümer bzw Hauptbesitzer bietet stets logischen IO an seinem Ausgang an. Die höheren Hierarchie-Instanzen sind gezwungen, logischen IO zu verwenden, wenn sie in den (temporären) Besitz eines Datenblocks gelangen wollen; der in Abschnitt 3.3.3 eingeführte Referenzzähler dient zur Verwaltung der „Ausleih-Rechtsverhältnisse"; im juristischen Kontext würde man dies als „Schuldverhältnis" charakterisieren. Ein „Schuldner" muss irgendwann seine „Schulden" wieder „zurückzahlen"; dies geschieht in der hier vorgestellten Archtektur durch korrekte Paarung von put.
• • Ein Eigentümer betreibt an seinem Eingang ausschließlich physischen IO; die unterliegenden Instanzen brauchen nur diese Betriebsart zu unterstützen.

The distinction between logical and physical IO on nests introduced in Section 3.1 corresponds to the concept of ownership and ownership in the following way:

• • An owner or main owner always offers logical IO at its output. The higher hierarchy instances are forced to use logical IOs if they want to get into the (temporary) possession of a data block; the reference counter introduced in section 3.3.3 is used to manage the "lending legal relations", which in the legal context would be characterized as a "debt relationship". A "debtor" must someday "pay back" his "debts", this is done in the here presented Archtektur by correct pairing of put.
• • An owner operates at his entrance only physical IO; the underlying instances only need to support this mode of operation.

However, it makes sense that intermediate entities like dir_ * should have both logical and physical IO competencies. This not only allows the use of the new architecture in MMU-free hardware such as embedded systems, but in theory even the mixed use of such processes that run in virtual address spaces, in addition to MMU translation-free processes ¹¹⁹ .

5.2 Recovery of property

As in real life it can also happen in an operating system that a "debtor" does not pay his "debts," or not paid "on time." The introduction of a "dunning" is in principle suitable to improve system throughput or in desperate Lack of situations at all to allow further work.

These operations go through a building block hierarchy in the opposite direction, ie from the owner to the consumer. Consumers are asked or forced to return the resource (a data block with the specified logical and physical address, or a lock of the specified type). The urgency parameter can take one of the following values:
ask It is only asked if a return of the resource would be possible without major effort and disruption of the operation. The receiver needs nothing to do except the boolean success feedback.
try The recipient is requested to return the resource if it does not disproportionately disrupt the operation. An exact time for the return is not required. command The recipient is requested to return immediately (ie before the success feedback). A refusal of the return by return delivery of success = false is only permissible if the recipient has to cease his activity because of the missing resource.
force The recipient must immediately return the resource, even if it forces him to stop working. If he still refuses ¹²⁰ , all his resources will be "confiscated", ie treated by the owner as if they had been returned, and there will be none in the future Operations executions that have been commissioned or are still being given by the Recipient Instance.

The notify _ * - operations have the character of an exception and are Conceptually with the signals from Unix and other operating systems comparable. In principle, therefore, races are between notify _ * operations and request or return operations of the owner possible. These races also occur in comparable situations in conventional Operating systems and are in my view inherently (see discussion in Appendix C). Although races can be through architectural measures avoid in principle (see Annex C), but i.a. at least in distributed systems at the expense of achievable parallelism and performance, because at least there the race problem is inherent and will be solved anyway got to.

A question independent of the problem of race separation concerns the "lawful" exercise of "brutal force", in particular the force mode. It goes without saying that an owner or principal owner can exercise great power over anyone who has received something from him as a sub-estate, as he can insist on recovery even if it endangers the existence of the sub-owner. Since ownership is, in principle, independent of the access rights discussed in Section 2.7, one might ask whether this power position could not be inappropriate, especially by hierarchically subordinate authorities. There is a principal answer to this: no. Whoever (in whatever way) has once been given the power to manage certain resources, can use this power inappropriately when allocating resources. He can theoretically act "vicious" at this point in time and circumvent any access restrictions, a typical example of which is memory management, which can compromise all the protections of the entire system based on it ¹²¹ The right of recovery does not require additional trust in this view, and if one can not trust an entity, then one must not entrust it with the administration of property or sub-estate (eg by choosing an appropriate one) Division of power ensures).

It gives more reasons the deprivation of any resources to a mandatory mechanism in future-proof operating systems. Mainframe computers support since long the so-called "hot plugging" of hardware components, So the exchange in the middle of ongoing operation. This does not apply only CPUs, the resources in almost all operating systems extractable represent, but also memory modules. The problem of the term exchange also appears in the IO area such as at RAID on; in safety critical Applications will be a prophylactic replacement of main memory modules sometimes even regularly. The ability for replacement during operation requires a mechanism with which the deprivation of resources is carried out in an orderly manner can.

Microsoft has integrated the concept of opportunistic locks [OpL] into the operating system interface of the newer versions of Windows, making application programs available for at least some applications. Opportunistic locks ¹²² are intended to speed up the cache coherency problem in distributed systems through the deliberate deprivation of resources; if there is no current need for withdrawal, then the time-consuming passing of the resource through the network is avoided ("aggressive caching.") In the model presented here, brutal violence withdrawal is seen as a last resort, in the next section A further fundamental difference between the speculative locks favored here and opportunistic locks is that the returns in the try mode do not involve the return of the entire locked area, but only a part of the cache This is particularly advantageous in combination with the speculative request for increased address ranges by the try_address and try_len parameters (see Section 3.3.5.) The distinction between a core region and a speculatively extended region is also in notify_lock so that the recipient can get a He himself decides how much he can return to his work without major hindrances.

5.3 Synchronization between Copies: speculative locks

Distributed systems differ from the perspective of the presented architecture mainly ¹²³ by a property from a stand alone machine: that is the access or latency of remotecapable and mirror devices, and the maximum data rate that limits its throughput. This problem occurs in the form of the well-known "memory gap" even in standalone systems and is known as bottles neck problem long known, for example, in virtual memory as Thrashing (see [DS72]) can express. For distributed systems, the specific problem is only in the place (hierarchy level) where the bottleneck is located.

to solution There are two proven basic strategies for the bottleneck problem: you try to bottleneck through hardware upgrade expand, and / or the solution a task to reduce the burden. While in the hardware classic peripherals permanent in the past Advances in both latency and throughput have occurred and are expected to continue such progress in spatial widely distributed systems only in throughput, not in contrast the latency possible (see [TL93]), since communication is limited by the speed of light becomes. Therefore, is unnecessary Traffic or unnecessary Waiting for the execution of distributed system operations even more urgent as in stand-alone systems. The architecture presented here attaches particular importance to asynchronous communication for this reason.

As already described in section 4.1.2 (block buffer) the purpose of a cache in the decoupling of bottlenecks and the reduction of it ongoing transfer operations. While at standalone computers Configurations with only one central buffer instance are possible, is the use of cascaded distributed caches (buffer instances) in distributed systems for performance reasons de facto inevitable. Cascaded caches lead inevitably to the well-known cache coherence problem.

The Cache coherency problem let yourself in the scheme of the terms used here in the following way formulate: there are multiple owners of the same logical resource available.

in the Law emerges this phenomenon in the terms community property (e.g., in condominium companies) and joint ownership (for example, rented by an association) on. in principle Several owners are equal, and they have to to deal with each other in matters of ownership; This happens in the so-called internal relationship. The reason is that a possession may have exclusive usable properties, so that one uniform and / or simultaneous use by all owners is not always possible.

The Dispute over Exclusively usable resources are found in traditional stand-alone operating systems preferably by delegating the administrative tasks to a central Instance (e.g., a lock manager). This solution has the advantage of higher Simplicity at low cost, as by the delegation practical negligible Latencies arise. In a distributed system, however, there is one Delegation to a single instance i.a. because of the communication latencies very expensive.

you can think of worst-case access scenarios in which the Latency costs of a distributed system inevitably with each individual access have to arise because they are due to a "sufficiently malicious" task can not be avoided (analogous to the working set model). By the way, this is true also for Caches of standalone systems that you also with such Access patterns can burden them with the well-known thrashing effect show that they can almost completely lose their effectiveness. For stand-alone systems The long-known principle that thrashing is only preventable applies is when the working set [Den68] matches the load in the cache. These However, a long-known basic rule also applies in a distributed system with several caches, but in a sharpened form.

Let's look at the following scenario ( 31 ) of several locally distributed caches, which I call "hierarchically high-level caches", which are connected to a common base cache.To have any decoupling effect from the high-level buf fer instances, their working sets, based on the temporal magnitude of the communication latencies, be "reasonably disjoint". Otherwise, in analogy to [DS72], a thrashing effect inevitably occurs between the high-level buffer instances, which is handled in the hierarchy structure selected here via the base buffer instance below and can not be eliminated by enlarging the caches, such as Denning has shown very clearly a long time ago. In my opinion, there is no herb at all against this type of thrashing: it is inherent in distributed systems that modified data must somehow be brought to the location of the other buffer instance if they are absolutely necessary there from the task, and that inevitably costs Latency (because the wind speed is not bypassable as a natural constant). So I see no other way than to design the task so that such thrashing does not take place. A necessary condition for this is that the working sets at different locations must be reasonably disjoint.

Under Assuming that the working sets of the high-level buf fer instances disjoint, the solution looks the problem as follows: there is nothing else to do to determine as the working sets reasonably accurate. This makes one exclusively inherently cached by nature. The situation looks different at most then booting when loading the upper cache instances with data in addition speculative manner, e.g. in the so-called preloading.

• 1. Die Caches seien jeweils genügend groß, so dass alle insgesamt benötigten Datenmengen in jedem einzelnen Cache Platz haben.
• 2. Die Datenübertragungs-Rate sei näherungsweise unendlich groß, die Latenzzeit dagegen ein fester Wert echt größer Null.
• 3. Jegliche Änderung eines Datums werde sofort an alle anderen Cache-Instanzen propagiert (was wegen der unendlichen Datenübertragungs-Raten auch kein Problem darstellt); diese Propagation kostet näherungsweise nichts.
• 4. Welche Version eines Datums während der Kommunikations-Latenzzeiten an welcher Stelle zur Verfügung steht, wird idealisierend als ständig überall bekannt vorausgesetzt.

To analyze preloading, let's look at the best case, where we make the following idealized assumptions:

• 1. The caches are each sufficiently large, so that all the data required in total have space in each cache.
• 2. The data transfer rate is approximately infinitely large, while the latency is a fixed value really greater than zero.
• 3. Any change to a date is immediately propagated to all other cache instances (which is not a problem because of the infinite data transfer rates); this propagation costs approximately nothing.
• 4. Which version of a date is available at any point during the communication latencies is ideally assumed to be constantly known everywhere.

In spite of this best possible Assumptions that are no longer under the given spatial distribution There can still be a trashing between them here high-level caches take place, given only the requirements designed by the task enough "vicious" Is this malignancy but not given (because the working sets of all participant instances disjoint), then never needs any buf fer instance to wait for another. This gives us the best case of which can even be achieved with the help of caching strategies, namely the total decoupling of all activities and with it the illusion that latencies are not available.

Since the assumptions made are of course not true in practice, ¹²⁴ the question is how to approximate the best case. For Assumption 1, there are long known and proven strategies of adapting caches to the working sets of requirements, especially LRU and LFU. To solve the problem 2, the explicit prioritization of the data transfers is used in particular in hardware architectures (for example in processor cache hierarchies): in the case of transport through a bottleneck, those transport orders whose execution depends on other activities must be treated more urgently; on the other hand, speculative transport orders should definitely be given a lower priority in order not to impede more urgent activities by blocking the neck of the bottle. This is made possible by the IO priorities in the architecture presented here (see Section 2.8.3). The problem 3 can be solved by making any changes basically immediately ¹²⁵ by generating an IO-order (transfer operation), but by default only with background IO priority, which is increased only in case of higher urgency. Problem 4 requires a more detailed analysis:
As already explained in Section 3.3.3 and in Section 5.1, the management of possession requires a transient assignment of the ownership status (eg as a reference counter, possibly also the version assignment). This status is linked to the location for which the respective (sub) ownership status is managed. Since all high-level caches are consumers from the perspective of the base cache, they, like all other concurrent consumers, must adhere to a multi-* behavior in order to ensure the determinant for their respective consumers. It follows in particular that locks must be passed in principle down to the basic cache, otherwise the behavioral models could be violated. If you passed each lock individually, there would be a delay in communication latencies each time, which would be catastrophic on throughput. However, this obligation to pass is a minimum requirement that may be exceeded. The idea is that when a lock is requested for the first time, the granularity requested by the end user is not passed on, but preferably a speculatively larger address range (eg an entire sub-nest or an entire directory nest). A suitable mechanism has already been presented in Section 3.3.5 (parameters try_address and try_len). If one of the most up-to-date caches has been able to reasonably speculate on the working set of its consumers, then it does not need to lock up its consumers' lock requests every time they take their way to the basic cache. Instead, it can accept the already received speculative ownership without waiting give their consumers as a sub-estate as soon as they make a corresponding request. It should only be noted that speculative, previously requested lock types must result in the correct semantics for subsequent demand from the end consumer; In general, instead of a read-lock, one will have to speculatively request a write-lock in order to guarantee the up-to-dateness of the latest version (otherwise other instances could change conditions that lead to an unnoticed obsolescence of the speculatively requested version).

Speculation about the end user's future working set may be misleading in that oversized areas were requested by the base cache, which would later be needed by other high-level caches ¹²⁶ . False speculations can be corrected by recoveries using notify _ * operations. Basically, the base cache can generate corresponding notify _ * operations to the current owner instance (on) upon requesting already issued locks. If he notices the differences between assigned core and extension areas (and possibly from later added core areas by the new owner in a timely manner, but asynchronously informed), he can also refrain from providing "hopeless" recoveries that concern assigned core areas. If possible, reclaims of core areas should only be made for those address areas that another cache really needs up-to-date.It is the fault of the wrong speculator, possibly even larger areas than the currently required or even larger than the proposed extension area to the base cache In addition, a return is spontaneously possible at any time, for example, if it was recognized that a certain area is no longer needed in any case.

All in all this approach causes a speculative pre-distribution of Resources that are subsequently corrected by the current requirements becomes. The return Speculatively requested resources can come through different strategies respectively. A possible Return Strategy is the one between the nearest indeed self-occupied area and the reclaimed area halve speculatively requested range, ie half further to keep the other half to the reclaimer. If the working sets of end consumers are disjoint and approximate are connected, then this results in the worst case, a logarithmic number of reclaims (in dependence of the size of the item to be split Address range). After this at most logarithmic number of recoveries is the previously unknown exact course of disjoint working sets been found empirically and there are no further recoveries more instead (steady state of the system). After the swing No further synchronization is required, provided that the working sets do not change so that the above best case is approximated relatively well. For "slow" changes to the working sets may occasionally find recoveries instead, these have a relatively low weight in the total all operations; so here is also the best case relative well approximated. If the working sets overlap too much or too high a rate of change it can come to a thrashing, but according to the above reasoning in principle unavoidable.

6 Generic Operations

Generic Operations are operations that have a polymorphic interface callable. are. In operating systems, the paradigm of genericity or the Polymorphism has been used for a very long time; find known examples u.a. at polymorphic core interfaces like ioctl in Unix, or in the operation jump tables of IBM operating systems, the different types of polymorphism as early as the 1960s implemented.

Before we come to the study of the types of polymorphism, I would like to clarify what an operations call is at all:
An operation call is the passing of information from a caller instance to an agent instance.

To this definition is the return of results, e.g. in result parameters, also an operations call, only in the reverse direction, i. from the original editor back to the original one Caller. In this case we speak of an operation call pair. Operation calls or pairs can be done in different ways realize. Known implementation types are e.g. procedure calls by handover parameters on the stack of a programming language runtime system, or the RPC (Remote Procedure Call). First case leaves only the synchronous call, the latter case also the asynchronous call. Other well-known implementation types are the start of control flows (asynchronous Behavior), or the passing of flow control in a coroutine model by calling a transfer operation (this causes synchronous behavior from the perspective of the overall system).

I would like to focus on another well-known way of realizing operation calls: the so-called message paradigm ¹²⁷ , which often appears in the context of CSP (see [Hoa78]), but in principle is independent of sequential control flows. The news paradigm is fundamentally used in hardware and is behind the widespread read-write interfaces, for example information can also be passed on from one instance to another.

you should definitely make it clear that between a pure news broadcast and an operation call at all there is no difference in principle. Such a difference arises only through the interpretation of the message by the recipient, as well possibly by its reaction to the interpreted message.

This means for our operating system architecture that we use to realize generic operations do not have to introduce new concepts, but already in detail featured abstractions nest and building block can use.

Concrete If this is e.g. realized in the following way: A nest instance s becomes a so-called operations nest as a dynamic attribute assigned or with the help of its own elementary function get_ops (s). The Operations Nest is used to exchange messages for the generic ones Operations that are performed on the associated nest s should. Inversely, the associated one can be assigned to a surgical nest op Make nest accessible through an elementary function get_nest (op). It then applies get_nest (get_ops (s)) = s.

To the Exchange of messages will be dealt with in section 3.3.8 Elementary operations get_address, put_address, get, put, transfer and wait used. The operations nest is allowed at any time contain several operation calls and is therefore suitable in principle, about the functionality job queues, device driver queues etc. perform.

In any case, to transfer the messages in an operations nest, it is necessary to use elementary operations ¹²⁸ that are bound to an interface mechanism in Section 2.3.2 and that first implement the concept of generic operations at a higher level of abstraction. Theoretically, it would be possible to dispense with the implementation of the elementary operations in the associated nest and to execute these exclusively by generic operations in the corresponding operations nest. Not only for performance reasons, but also for reasons of symmetry, I propagate the reverse methodology that elementary operations should be invoked in both ways (and should do the same). It does not matter if elementary operations are invoked directly on the associated nest or indirectly commissioned through the operations nest ¹²⁹ . However, it would be wise to lock and unlock operations exclusively through generic operations, and thus no longer as elementary operations, since they are not needed for the production of generic operations; Thus, the interface mechanisms of Section 2.3.2 would satisfy the property of minimality.

Farther An Operations Nest offers the opportunity for atomic bundling of lock operations. This will be several Lock Operations descriptions packed in a common data package. The execution is done either together as an atomic unit or not at all. This is especially the craftsman problem [Jür73] without introduction solve further concepts. When bundling several wait operations to realize the semantics of disjunctive waiting without introducing additional concepts.

Now on the problem of polymorphism. Callers and editors must have one Interpret Generic Operations Message in Matching Manner otherwise a malfunction of the system will occur.

In order to keep information about how Nest's content is to be interpreted, the concept of the meta-nest is envisaged (see Operation get_meta in Section 3.4.5, see Section 4.2) ¹³⁰ . This can now be transferred analogously to operation nests. The operations meta-nest is intended to convey a consensus between the caller and the editor about the data formats or data types to be used.

• 1. Eine Typprüfung (d.h. ein Test, ob zwei Datenformate zueinander passen) braucht nur zur Laufzeit erfolgen. Es gibt genügend Anwendungsfälle, wo dies auf jeden Fall erst zur Laufzeit geschehen kann; dynamische Typprüfungen sind also unbedingt erforderlich und können statische Typprüfungen notfalls vollständig ersetzen¹³¹. Als Konsequenz hieraus brauchen statische Typprüfungen höchstens bei einfachen Grund-Datentypen und nicht notwendigerweise bei komplexen Datentypen vorgesehen zu werden. Dies vereinfacht ein Typsystem enorm.
• 2. Welche Typen (d.h. Datenformate) ein Bearbeiter akzeptieren und bearbeiten kann, kann nur dieser alleine festlegen. Typ-Informationen dienen zur Einweg-Kommunikation zwischen Bearbeiter und Aufrufer; damit kommen komplexere Mechanismen wie Typ-Inferenzsysteme nicht auf Systemebene¹³² in Frage.

So we need a type system, as it has been used in programming languages for a long time. In the literature of this area, innumerable variants of type systems are treated. Selecting a specific type system is easier if you consider the following requirements that have traditionally played a major role in operating systems:

• 1. A type check (ie a test of whether two data formats match each other) only needs to be done at runtime. There are enough use cases where this can happen at runtime; Dynamic type checks are therefore absolutely necessary and can completely replace static type checks if necessary ¹³¹ . As a consequence, static type tests at most need simple basic data and not necessarily for complex data types. This enormously simplifies a type system.
• 2. Only those can decide which types (ie data formats) an editor can accept and edit. Type information is used for one-way communication between the engineer and the caller; This means that more complex mechanisms such as type inference systems can not be considered at system level ¹³² .

It It is clear that despite these limitations many different Type systems and even more concrete implementations of the same in question come. In next Section, I will introduce two simple type system, the important one Basic functions should cover and only as examples understand.

6.1 Example Type Systems

Some Operating system designers have refused in the past Introduce type concepts, what u.a. to the historical split between operating system and Database constructors contributed. Arguments for this were or are still that types firmly anchored in the operating system the flexibility mitigate the interfaces and on top of that performance costs. I hope to be able to relativize this view. It I do not care about introducing firmly anchored types, but on the basis of generic interfaces, the declaration of any To enable types by being expandable. Type descriptions provide an optional Concept that can also be omitted; then you get genericity in pure culture. Properly used, it can complement generic interfaces and by traditionally hand-coded operations (e.g. using assembler into the 1970s) automated become. I try to show in the following examples that excellent performance of type tests attainable by the choice of suitable language classes and codings is.

6.1.1 Minimal type system

Here is the question of what a type system must necessarily contain making generic operations reasonably usable and usable are. Everything we do not need, we try to get away and to relocate to runtime tests by the editor.

If an operations nest should allow several different generic operations, then there is information that must be present in both the caller and the agent:
the name of the operation.

A simple implementation of a minimal type system is that the meta-nest of the operation nest contains a list of implemented disjoint operation names. For example, this list can be realized as a series of packages whose boundaries are displayed in the adjoint nest of the meta-nest. For example, text strings may be used for encoding the operation names, which are preferable to integer constants ¹³³ . More does not need to be contained in a minimal type system ¹³⁴ ; Whether the number, sizes and values of the operation parameters are correct can be checked by the processor himself and, if necessary, react with the return of an error message.

6.1.2 Simple extensible type system

The minimal type system just presented is already expandable in that the value set for the coding of the operation names can be chosen so large that future extensions to new operations are practically unlimited. It is now a matter of the question of interface extensions, which can be classified under the heading "extension genericity" (see section 2.1.2) ^135. With the architecture presented here, it is absolutely necessary to scrupulously examine the use of extension genericity Whether the same effect is not achievable through compositional generosity (see Section 2.1.3.) Compositional genericity generally takes precedence over extension genericity, and this philosophy is an important distinguishing feature of the approach presented here compared with most competing approaches.

In the field of programming languages, type systems are considered to be algebraic structures for which an abstract syntax can be given and usually only given. This is not sufficient for our purposes: an operating system must also specify the specific data formats (so-called call conventions), since the system interfaces should apply across different caller types, in particular to enable connection to different programming languages and runtime system models , We therefore need a specification of the algebraic structure in conc ter syntax ¹³⁶ .

Context-free grammars are known to be suitable for specifying a concrete syntax. However, in their general form they bring with them the problem of ambiguity: if carelessly used to describe data formats, it may happen that a concrete data format pattern allows different interpretations. From the theory of formal languages it is known that the membership of any grammar in the class of uniquely context-free languages is not decidable; Fortunately, however, there are decidable subclasses such as the well-known LR (k) or LL (k) grammar classes. These are not only decidable, but sufficient for practical purposes entirely of ^137th

I would like to go a step further and show that, for the purposes of operating systems, the class of LL (1) grammars that are additionally in Greibach normal form ¹³⁸ is sufficient. The word problem or the parsing problem is trivially solvable in these grammars, since, for example, the well-known method of recursive descent can be interpreted in an interpretative manner directly on a grammatical encoding without having to calculate the FIRST sets required by LL (1) because they trivially match the first terminal symbol with which every grammatical rule must begin because of Greibach's normal form. The necessary parsing decisions during recursive descent become trivial.

Around make sure that a Greibach grammar is definitely the one Satisfies LL (1) property, There is a simple method that is easy to learn and master should be: It is claimed as a substitute requirement for the LL (1) property that no different rules of production of the form X → aα and X → aβ with the same Nonterminal symbol X and same terminal symbol a, but different Sequences α and β occur allowed to. This requirement can be keep in mind that for α or β a new Introduces non-terminal symbol Y, that perform the role of the previous residues α and β together and take over should. Because all productions for Y again subject to the same requirements arises the LL (1) property when designing the context-free grammar a person by itself. I call a Greibach grammar with this replacement requirement a type grammar.

• • Die Schachtelung
• • Die Sequenz
• • Die Alternative

A type grammar directly translates the following known basic principles of data structure design into easy-to-use grammar rules:

• • The nesting
• • The sequence
• • The alternative

Nesting of data formats is expressed by the distinction between terminal and non-terminal symbols; a non-terminal symbol can be reused in various places. A sequence of data formats ¹³⁹ is expressed by concatenating terminal or nonterminal symbols in a grammatical rule; mathematically, it represents a Cartesian product. Alternatives to the same nonterminal, unlike arbitrary context-free grammar rules, must always be initiated by mutually different terminal symbols ¹⁴⁰ , so that the respectively correct alternative can always be recognized at the beginning of a recursive descent by a trivial discriminator ¹⁴¹ .

Unlike programming languages, this methodology is used quite dynamically in operating systems; In general, the recognition of a data format can not be anticipated by the type system of a compiler, but must at least be feasible at runtime during the wiring operation. For this purpose, the runtime interpretation ¹⁴² of data formats using context-free grammar rules is particularly suitable. Performance increases by pre-translation of type grammars into deterministic pushdown automata are not excluded ¹⁴³ .

For example, a concrete implementation using interpretable type grammars might look like this:
Nonterminal symbols are represented by upper case ASCII strings and underscore. An example would be "IP_ADDRESS".

Terminal symbol classes behave logically like nonterminals, to which no rules can be defined, since there are already built-in rules for them ¹⁴⁴ . They are represented by lowercase ASCII strings, which are appended with an ASCII-encoded number that describes the amount of space in bytes. Examples are "int1", "int2", "int4" or "int8", the signed-to-be-interpreted machines or "space512" for an uninterpreted data block Further terminal symbol classes such as "bigendian_unsigned_int4" can be invented later at any time; the meaning behind the name does not matter for the parsing of the data format, only the space requirement is decisive.

terminal symbols are written by consecutive-writing a terminal symbol class and a concrete expression noted in parentheses. Examples are "int2 (7)" or "int4 (-1)". For Character strings of variable length you can introduce a convention of the kind "string ('Name')", at the actual space requirement from the text between the quotes results.

Grammar rules can be encoded, for example, in the following way:
"STRUCTURE = int1 (0); substructure; int4;"

As can be seen, the semicolons are not just separators, but also used as the terminator of a rule. The type grammar property is satisfied, if there are no two rules until the occurrence of the first semicolon coincide with each other; all must continue Rules for the same nonterminal "STRUCTURE" behind the equals sign with the start same terminal symbol class. If a nonterminal should not or may not contain alternatives, then, as a special case, one Terminal symbol also allowed "0 (0)" represents a discriminator, which occupies no space and of which therefore only one shaping (so that no further alternatives are allowed as a result).

For the start symbol of the grammar, one can introduce a convention, for example a non-terminal symbol "OP" for the description of operation nests, or "DATA" for the description of data formats in persistent nests. The description of the four basic operations then looks like this, for example:

This Example represents only the most important basic elements of a type system before and should be for the practical use can be extended by further expression possibilities, for example, field names describing records or other terminal classes to describe bit fields or range types, as well as alignment conventions ("Alignment"). With the help of others Conventions, for example, the automated verification of validity of address ranges or descriptors possible, so they are not more ad hoc tested as in previous operating system implementations "by hand" must become.

6.2 Connection with object orientation

• • Unterteilung in Objekt-Instanzen und Klassen: Nest-Instanz versus zugehöriges Meta-Nest
• • Unterteilung in Attribute und Methoden: Daten-Nest versus Operations-Nest

32 shows the relationship of the four introduced nest species with known concepts of object orientation. The dashed dividing lines should indicate a subdivision of the field according to two different criteria:

• • Subdivision into object instances and classes: Nest instance versus associated meta nest
• • Subdivision into attributes and methods: Data Nest versus Operations Nest

The Relations of instances of the respective nest species are indicated by arrows with caption of the associated Access features marked. A Nest instance stands with her associated Operations Nest instance in a one-to-one relationship, just like when packaging Attributes and Methods in Object Orientation to an Object Instance. The status of an object instance is stored in the nest instance.

Of the Connection with inheritance is possible represented by two adaptation modules, the corresponding transformations on the nests or meta-nests.

When downcast (see 33 ) the interface is extended; new attributes can be added to the attributes and methods available at the base_class input, which are provided at the son_class output; if necessary, the implementation (or the behavior) of some methods can be changed (overridden methods and virtual methods). Since the extent of the stored status can increase, an input tmp is provided to accommodate this. However, with appropriate space allocation rules in the base_class nest, the status can also be stored there, making tmp redundant.

When upcast (see 34 ) only the interface is reduced, so that not all attributes and methods are accessible from the outside ¹⁴⁵ (principle of concealment).

• • Austausch einzelner Methoden-Implementierungen zur Laufzeit, und zwar unabhängig von einer Klassenhierarchie¹⁴⁷
• • Änderung der Repräsentation von Attributen (beim Erweitern der Schnittstelle und/oder zur Laufzeit); vgl. Anhang B.
• • Aufspaltung eines Status-Raums in beliebige Kombinationen von Teilräumen¹⁴⁸
• • Einfache Verwendung beliebig unterschiedlicher Methoden-Sätze¹⁴⁹

It can be seen from this description that the concepts of object orientation represent a special case of the methodology presented here. The abstractions nest and building block make it possible to realize the following concepts, which as a rule are not provided for the usual ¹⁴⁶ forms of object orientation:

• • Exchange of individual method implementations at runtime, independent of a class hierarchy ¹⁴⁷
• • changing the representation of attributes (when extending the interface and / or at runtime); see. Appendix B.
• Splitting a status space into arbitrary combinations of subspaces ¹⁴⁸
• • Simple use of arbitrary different sets of methods ¹⁴⁹

6.3 Connection with the Functional paradigm

The basic idea of a lambda device (see 35 ) is to provide a universal interpreter whose actual operation is determined by the content of the expr input in an appropriate encoding. At the output f special generic operations are provided, which are indicated by the dashed lines of in 36 featured apply can be used. A function generated by lambda does not represent a complete space instance with a state, but merely provides the operations that implement the function f when it joins to a working nest instance f (x) using apply and an argument x become. Since, in addition to the status held in x, further space requirement for status information for the calculation of f (x) may be required, a tmp input is provided as usual for such cases.

The Operation is outlined as follows: if at the output f (x) any Called nest operations, then call the generic Operations of the f input with the appropriate data arguments on, which it has previously won from x (and possibly passes others from tmp recovered auxiliary storage that is instance-specific).

features higher Order [Fie88] can be created on the same principle. At the exit of apply, only fully functional nests do not appear but only surgical nests using additional apply instances yield only normal usable nests.

building blocks and her wiring is for already taken themselves universal constructs, for example also with theoretically interesting descriptions like the Hotzian X-categories describe.

Farther is to mention that theoretically known methods for term or graph reduction also by ballasts in the control lines of control (Section 4.2.1). Theoretically could you can also use syntactic evaluations with the help of the block compilations operated relationships without the state of the involved Nests to use. The block wirings are used to represent an algebraic Structure abused. This theoretical context illuminates However, the importance and necessity, in practice very much the information stored in the wiring and not theirs always easy to control consequences.

Although in practice the connection with functional paradigms shown here should rather not be used in the theoretical form of the general lambda calculus (since nests are not used as competitors) In addition, more specialized forms of functional thinking and design methods may well have valuable practical applications. Universal interpreters do not necessarily have to consider purely functional paradigms, but can in practice be realized in a "shirt-sleeved" manner, for example by a Perl interpreter [Haj00], which derives its program code from an input separate from the data to be processed ^150. For example, I have prototypes developed very quickly.

6.4 Correlation with Database Schemes

relational Database schemas can be generated using nests and building blocks, convert to database instances, and the instantiated ones Process data.

Database tables and indexes can be stored in a nest, and the associated (sub) schema is kept in a suitable representation in the meta-space or in the attributes. By a building block gen_table (see 37 ), A pure schema that contains one or more meta descriptions of tables, in one or more ¹⁵¹ corresponding tables are instantiated. The persistent status is kept in the tmp input and made available at the output. It is ensured and checked that the instantiated data records correspond both syntactically and semantically to the schema structure.

Fixed-length records are most easily stored as a contiguous array. In this case, the adjoint nest does not necessarily have to represent the boundaries of each individual record, as this information can be easily calculated. With variable data record length, however, the representation of gapless packets (see Section 3.4.1) is appropriate in the adjoint nest. If, for reasons of uniformity, this type of representation is also required for fixed data record lengths, the contents of the adjoint nest can be calculated internally in a virtual way, without taking up any space in the persistent memory. Another possibility is to separate the components of fixed-length data sets from those of variable length so that a high-performance array representation of the data sets with references to a heap area accommodating the variable parts; such references conceptually correspond to the record descriptions in the adjoint nest and should be centralized in one place for reasons of uniformity; the concept of the adjoint nest is particularly suitable for this ¹⁵² . In order to obtain a good combinability of building blocks, these conventions should be defined uniformly.

Nothing has been said yet about the sorting of records. It is possible to keep a table sorted by a primary key right from the start (cf. 38 ). However, because foreign keys allow independent views, it is convenient to keep the keys in the nest regardless of their type and number. For example, a key representation can be an array of index numbers of the records sorted by key. Insertions and deletions of records are then accomplished by move operations on the respective arrays. Of course it is also possible to use classical representations like B ⁺ trees, but they are much more complicated and difficult to interpret. Since nests should preferably represent universal genericity by means of very simple data structures, I consider the use of sorted arrays more favorable, especially since a cheap move operation is available for the administration of these array structures. High-performance search structures like B-trees. do not become superfluous; they are merely used elsewhere in a building block hierarchy, namely in the generation of dynamic nests (building block map in Section 4.1.3).

The operations of relations algebra such as selection, projection and Cartesian product formation through different join variants (see 39 ) can be represented and executed directly by building blocks. Details are left to further work on the integration of databases in operating systems.

7 multiversion models

In This chapter aims to examine how the functionality of transactions integrate into the nest interface in a simple generic way leaves. The goal is not the complete one Cover all conceivable multiversion models, but the exemplary selection and presentation of some (hopefully) for practical For purposes of appropriate models, the most common Transaction semantics should provide universal genericity.

Historically, transactions [BHG87, LS87, GR93, Elmbe] had the goal of providing each consumer with a single-user model, despite concurrent activity, so that programmers would not be interested in Pa Rallelität needed to take care of. After extensive research into synchronization and recovery, it was discovered that, despite the single-user baseline, we were dealing with versions of data objects; Without versioning, resetting is inconceivable. Subsequently, multiversibns variants of transactions [VGH93] were examined, in particular time stamping, time domain addressing. In the following I presuppose the knowledge of the essential basic concepts from the database world from the mentioned literature with the reader. For our purposes, generic transaction mechanisms at the nest interface are required, with which as diverse as possible transaction models can be implemented as a strategy through building blocks.

7.1 Requirements

• 1. Jede jemals durchgeführte Operations-Instanz auf einem Nest muss anhand eines Merkmals (z.B. Zeitstempel) wieder eindeutig auffindbar sein
• 2. Es können mehrere von einander unabhängige Zeit-Bereiche notwendig sein

In application areas such as financial accounting, there are legal requirements that enforce the subsequent understanding (reading) of all actions performed (operations) in the chronological order of execution (complete time-based documentation of all operations). In addition, there are independent factual criteria as temporal order features, under which carried out operations must also be retrofittable. A typical example from financial accounting is the difference between the document date of a document and the posting date: the sequence of posting documents does not necessarily have to be in the order in which they are valid (document date). In the journal of a financial accounting, all entries must be at least in the order of entry, in the account statements they should also be retrievable in the order of their material validity. These requirements can be generalized in the following way:

• 1. Every instance of operations ever performed on a nest must be clearly identifiable using a feature (eg timestamp)
• 2. Several independent time ranges may be necessary

Point 1 means that an "elephant ^{memory 153} " needs to be implementable because there are applications that require it because of legal requirements, and in other applications, if the overhead is disruptive, restricted models can be derived that target or automatically remove unneeded information. be forgotten ".

Point 2 seems at first glance to mean that due to legal or material requirements one or more total orders one or more time ranges to implement. This would be, however especially in distributed systems very hindering. The following considerations mainly deal with this problem.

7.2 General Model

One possibility would be the introduction of temporal half-plan concepts into the nest interface. A total order would then arise as a special case where this would be necessary due to requirements. This possibility is not further investigated here because of its high complexity ¹⁵⁴ .

Instead, I propose the following approach to the problem:
The idea of establishing a temporal total order between operation instances does not necessarily imply that the determination process itself must be done in a totally ordered order of time. It is only required; that the final result must be a temporal total; however, when this final result is calculated is another question.

This distinction between virtual time and real order of operation executions could be characterized as a lazy evaluation in determining the temporal order of operation instances ¹⁵⁵ . As long as a total order has not yet been finally determined, (temporary) partial orders can be effective. However, once made determinations can never be revised; this is nothing other than the consistent application of the persistence idea to the temporal ordering relations. Otherwise, however, persistence is independent of the achieved intermediate or final states of a nest.

Of the Final state of a nest is reached only if not only the Data contents and parameters of all executed operations instances, but also set the timestamps of the operations instances internally are. Consumers never become aware of semi-ordered ones Between states; at the latest the Querying temporal relations at the nest interface performs automatically to a determination (and thus possibly to a state change in the strict sense, even with a "simple" query).

The details Definition of previously (partially) indefinite temporal relations becomes more precise called; all temporal relations between operations of a nest be summarized precisification state called. Precision states must be consistent be, i. in a distributed system, two different queriers are allowed no contradictory Get answers to the same facts. The amount of all executed operations together with their parameters, but without the temporal relations, becomes data state called a nest.

Parallelism of operations is especially possible if there is no query of temporal relations of the preconditioning state (about because temporal orders for the one to be solved Problem does not matter). If never a query temporal Relations between operations instances takes place, then can a persistent memory in extreme cases, entirely uncorrelated operations instances whose chronological order is not fixed (one Of course, this may be done anyway). If two operation instances have a temporal relation to each other, could be determined implicitly with the help of a usage model. For example, could a particular usage model dictate that all Operations that rely on mutually overlapping address ranges of a nest, must be brought into a total order. It are however cases conceivable in which even this weak-seeming demand is not Fulfills to be (for example, when irrelevant operations implementations are easy ignored and never looked at again). Because continue very many different usage models are possible, I suggest ago, no assumptions about implicit dependencies to include between Operations instances in the Nest interface, but any temporal dependencies to make explicit. The realization of different usage models becomes the task of concrete building block implementations.

The most general multiversion model looks like that to everyone to be performed Operations instance must be specified in any form, of which other ("previous") operations instances them depends. The specification of the "earlier" operation instances does not need an individual acquaintance of all in question It can be preceded by different instances of operations quantity- or predicate-oriented Specification mechanisms.

Out I choose the multitude of temporal order specification mechanisms Below is a specific one and leave the investigation of alternative Mechanisms of further research.

7.3 Time Interval Model

The basic idea is, as a time base a physical ¹⁵⁶ Lamportsche pm [Lam78] with sufficient accuracy to use, however, assign each Operations instances no fixed time-points, but time intervals (see. Concept of linearizability in [HW90]). In contrast to firmly established consistency models, such as the linear consistency, which also allow partial orders in the final result, time stamp intervals can be subsequently reduced at any later time (special case of a specification): an original time stamp [t ₁ , t ₂ ] with t ₁ ≤ t ₂ can be converted at any time into [t ₃ , t ₄ ] with t ₁ ≤ t ₃ , t ₃ ≤ t ₄ and t ₄ ≤ t ₂ .

Such a reduction must always be carried out when, in the comparison, the time stamps of two operation instances op ₁ and op ₂ , written t (op ₁ ) = [t ₁ , t ₂ ] and t (op ₂ ) = [t ₃ , t ₄ ], a mutual overlap (ie, t ₃ ≦ t ₂ ∧ t ₁ ≦ t ₄ or t ₁ ≦ t ₄ ∧ t ₃ ≦ t ₂ ). The forced reduction operation ensures that subsequently either t ₂ <t ₃ or t ₄ <t ₁ applies ¹⁵⁷ , ie a commutation of the two operation instances is subsequently no longer possible. As long as the time stamps of the two operation instances are not compared by an implicitly or explicitly executed comparison operation, the intervals may overlap, ie there is no need to finalize the order of the two operations.

For the user This model looks like there is a total global Time. The internal realization, however, uses (temporary) partial orders. The presentation as a total external order, this model differs from explicit on semi-orders constructed models.

7.4 Container Operations: Locks

Already in the multiuser model (Section 3.3.5), locks were used to brace a set of access operations. In multiversion models, lock operations are analogously conceived as temporal and spatial containers that can accommodate a lot of access operations. The idea is only abstracting these containers as units for relationships between access operations, and abstracting from the details of the container-hosted operations and types of operations.

Lock Operations instances be construed as persistent or quasi-persistent objects ¹⁵⁸ that have a time and a local dimension and a mandate are assigned as the owner; Different transactions must run under different mandates. The spatial extent is the area of the virtual address space of the nest to which the lock refers. The temporal extent corresponds to the just introduced intervals on a virtual time axis, which is independent of the actual execution order. While the local extent is largely fixed (for example, once they have been negotiated as speculative locks, see Section 5.3), the temporal extent can be subsequently reduced at any time (clarification). A container may only accommodate such access operations that relate to a subset of the spatial and temporal dimensions. As a rule, the access operations inherited by a container inherit their temporal dimension from the surrounding container.

In 40 For example, write-lock instances are represented by rectangles with pointed corners, while read-lock instances are represented by rounded corners. Different write-lock instances must never overlap one another, ie not occupy the same area in the temporal and spatial dimensions. However, in the event of a conflict, write locks can always be subsequently reduced in size so that they fit next to each other on the time axis (due to the unique time stamp, see Section 7.3). On the other hand, read-lock instances may overlap one another.

The relationships between read and write-lock instances are given in 41 examined more closely. The drawn numbers in the boxes are intended to indicate the order of ^159, in which the respective locks to be set. Setting the dashed lock 3 is not possible because he would "hide" the indicated by dashed lines "view" of the previously existed Lock 2 on Lock 1 partially. If the order of Lock 2 and 3 were reversed then setting all three locks would be possible, but then the read lock would get a view of the smaller write lock instance. In the special case of 42 is a conflict resolution by subsequent reduction possible.

The following principle applies: Once granted (or used ¹⁶⁰ ) view of a lock on other locks may not be subsequently changed.

The The question is what is meant by a view of other locks should. Intuitively, it deals with the well-known semantics of memory a read operation or a read lock the state of the last in time before that change (Write-Lock or write operations) should see. The difference to the classical semantics consists only in that the time axis is a virtual entity on which the relations "before" and "after" are independent of the actual Execution Order (assuming a globally unique execution order at all exists).

7.5 Causal dependencies

The Generalization of the idea of a view of a lock instance on others Lock instances are called direct causal dependency. The generalization is that not just dependencies because of the (possible) View of other lock instances of the same address range as causal dependence but above it In addition, any other causal dependencies in the (quasi) persistent Präzisierungs-state model can be included on explicit request.

A typical application for the inclusion of externally specified causal dependencies is the Herbrand semantics classical transactions [VGH93]. Classic "syntax-oriented" transactions consider each write operation as causally dependent on all the previous ones the same transaction read objects. So-called "semantic" transaction models [Elmbe], on the other hand, try by knowledge of the inner structure of the Transactions only those causal dependencies as a consistency criterion in To consider that are actually present and used become.

We provide universal genericity in terms of different transactional models by making the explicit Specification of causal dependencies in the nest interface demand. The special case of complete causal dependencies all objects handled by a transaction can be relatively easy as a strategy through a suitable adaptation module to implement.

Concrete let yourself To do this: Read-Lock instances are automatically given a direct causal dependence from all the write-lock instances that deal with their clipping overlap the address range and those closest to the timeline before.

at Write-lock instances must be the caller of the write-lock operation specify a set of address ranges. From this set of address ranges becomes the set of temporally closest ones Write-Lock instances are determined, one of which is a direct causal dependency should be accepted. This type of dependency serves only as Information transfer for additional Conditions or properties such as serializability, compliance is a matter of concrete implementation strategies.

The following situation in 43 can be solved for example in different ways. In the initial situation, Lock 3 was defined as causally dependent on Lock 1 and Lock 2. The newly added Lock 4 intersects only the address range of Lock 1, but not that of Lock 3. Since he does not simultaneously override the address ranges of Lock 3 and 2, the admissibility of this operation is a matter of concrete strategy. I see the following possibilities:
You can allow the initial situation (first picture). Then, however, it must be noted persistently which version (namely Lock 1) has the concrete causal dependency. Otherwise, reducing Lock 4 as in the second image would result in an inadvertent change of the version that is causally dependent. The latter problem could also be avoided by avoiding unwanted version changes by not allowing such locks to be set. Due to the overlapping of Lock 4 with Lock 3, the special situation also allows for the special solution from the third picture, but this generally leads to a disability. The simplest solution seems to me to allow for "skipping" causal dependencies ¹⁶¹ that are built on the respective lock instances and not on the address ranges, skipping is allowed if both address ranges of source and target of direct causal dependency do not match overlap the address range of the inserted lock instance, however, additional conditions may be introduced for the permissibility of such "skipping" causal dependencies as a particular strategy; this includes, in particular, compliance with the serializability of transactions.

7.6 Timelines

Of the Attentive readers will already have wondered how unlock operations in a model that all Lock instances are supposed to work (quasi-) understands persistent objects and in extreme cases forever can keep (for example, in military or secret service Applications would understand at any time, who which which Read-Locks set and the associated Data has been inspected). The acting as containers for access operations Lock instances need be completed sometime. Complete means that the container no (subsequently delivered) operations accepted more for accommodation.

When created, each container is assigned a mandate or a set of mandates as the "owner" of the container.The state of a container is also defined at creation, but can be changed later and is a value from the following hierarchical list of actualities:
act_invalid The container holds invalid (ie ignorable) operations.
act_destroyable The container contains a preliminary calculation result that can be invalidated at any time (possibly asynchronously) by third-party mandates (not only by the owner's mandate), without resulting in irreparable damage.
act_optimistic The container contains a preliminary version whose validity has not yet been determined. However, a declaration of invalidity can only be made through the owner's mandate (see Optimistic Strategies in the Database Literature [VGH93]).
act_tmp It is a temporary (not yet completed) container to which new accommodation operations can be added at any time. Withdrawal of already hosted operations is normally not envisaged (sole exception: systemic failure or other catastrophic events).
act_close The container is closed, meaning that no new operations can be accommodated. The operations or their effects do not necessarily have to be stored persistently. A reopening, ie a change to a smaller state using lock, is then (and only then) permissible if there are no causal dependencies on this container.
act_freeze Like act_close, but a change to smaller states is no longer possible.
act_safe As before, however, the container and its container contents are persistent at least once stored and therefore still accessible even after simple system errors such as power failure.
act_multisafe The container (content) is repeatedly redundantly protected against more serious system errors.

For the states apply following rules: Creating a container is only with the actuality levels act_destroyable until act_tmp possible. An unlock operation sets the state of all the values swept by its address range and mandate-owned containers to a selectable one other level of actuality; State changes done by unlock with the exception of act_invalid only in ascending Direction of actuality levels. The state act_invalid is from act_destroyable to act_close off attainable (thus in particular from act_freeze no longer attainable); a once achieved act_invalid state can never leave become.

Farther should be noted that state changes in higher actuality levels only meaningful if all causally preceding container at least the same level of actuality achieved. If a causally preceding container is on act_invalid is set all of them causally dependent containers also be set to act_invalid. This corresponds to the cascading Rollbacks in classic transaction models.

The unlock operation thus allows both the classic functionality of rollback operations transactions as well as commit operations. One Rollback corresponds to the state act_invalid, the commit is ever After the required fault tolerance, an actuality level is controlled from act_freeze.

7.7 Interfaces of Lock Operatioen

7.7.1 Search intervals

A nest can be seen in the multiversion model as a two-dimensional space that has a local and a temporal dimension. In principle, you can access all parts of this room at any time. There are also search operations that can be used to detect lock containers in the nest. To specify search intervals, I propose the following conventions:
A search interval is a pair (start, delta), where start is the start and start + delta is the end of the search range. A search interval can refer to either the temporal or the temporal dimension. If the delta is positive, it searches in the ascending direction, ie if several lock containers intersect with the search interval in the respective dimension, after performing comparison operations and possibly reducing them (only for the time dimension), the Lock instance is delivered has the smallest value in the respective dimension and overlaps with the search interval. Negative delta searches in reverse direction.

The Simultaneous search for search intervals adr_search and time_search those Lock instances are delivered, which are in both Overlap dimensions with the respective search intervals. In this way is a search in a rectangular area of the place-time-space possible.

When Special case can still delta = + ∞ or delta = -∞ for unlimited search allowed, as well as start = + ∞.

7.7.2 Lock operations in the multiversion model

The lock operation from section 3.3.5 is included in the extension proposal presented here on multiversion models for methodological reasons in the two operations variants read_lock and write_lock split as they are slightly different Need parameter supply. However, they are also slightly different Designs of the interface possible, the uniformity maintained the interface of both lock types.

The speculative_set and adr_set parameters inherit the function of log_address, len, try_address, and try_len from Section 3.3.5. In addition, a proposal for the timestamp interval time pass set. In the result intervals adr_result and time_result, the actually possible location and time intervals are returned (if the setting of the lock is even possible). In any case, the location interval must at least include adr_set, the time interval may also be smaller compared to time set.

Of the Parameter act indicates the actuality level of the read lock to be generated. min_act, on the other hand, specifies an actuality level, all directly causally preceding write locks must meet at least. If in the direct causal dependency write-locks with too low level of actuality usually have to wait so long until this the required actuality level achieved. If you specify small levels of freshness for min_act, though the possible parallelism increased (see "dirty read" in databases), at the same time, however, the risk of cascading rollbacks and also the risk of inconsistent reading due to newly added ones Accommodations in causal preceding containers. For strict requirements to be complied with consistency conditions may thus u.U. the need Rollbacks are implied (see Schedules error security [VGH93]).

The causal dependencies are kept persistent in the most general multiversion model in order to satisfy the memory semantics even for later "predated" locks The Boolean parameter stable specifies whether the causal dependencies should be "stable" or later With stable = true, later in the time interval between the newly set lock and the causally dependent predecessor, no such write locks may be installed later, which will change the search result when (re) determining the . functional dependencies of all lock entities that may be affected can lead ^162. Thus, the owner determines a lock (ie the mandate or set of mandates) whether other locks are compatible with it or not, if you this property also transitive for all predecessors of the causal. Dependencies (eg by listing type with stable = transitive; the determination holds independently of the original stable state of the transitive preceding causal dependencies), then different transactional or consistency models can be arbitrarily mixed with each other without violating the respective intended semantics (this is in contrast to the prevailing opinion about the miscibility of different models ).

The Boolean parameter direct determines whether the created causal dependency must necessarily depend on the first actual write lock in the search direction, or whether outdated versions (eg in distributed systems) are tolerated. The latter option improves performance at the expense of less stringent consistency models and can lead to "skipping" causal dependencies similar to the PRAM consistency ¹⁶³ .

Of the Parameter aim serves as a substitute for the former Parameter child from section 3.3.5. It gives one of the values aim_address, aim_data or aim_both. This specifies whether only the address mapping function of the nest, or the data mapping function, or both versus competing Accesses are to be blocked (continue can thus also the admissibility the hosted types of operations are tested). Adressmodifizierende Operations such as move can be handled by data-modifying operations how to decouple transfer. To make better use of this ability, For example, you can introduce another adr_time parameter, the the time stamp to be used for the address mapping independent of dictates the data mapping. In particular, such mandates can an undisturbed Access the nest addresses, which themselves are not address-modifying Perform operations; These mandates then the address mapping appears as "pinned", although they of other mandates on the virtual timeline may have been changed.

For the location adr_set is similar to section 3.3.5 the rule that set earlier for the same mandate Locks (no matter where they are on the time axis) can be "hidden." Each Mandate has at most time at most a (unique) lock-instance mapping for each (sub) location area; this unique mapping continues to serve the correct version mapping subsequent get and transfer operations. The uniqueness will achieved in that again requested address ranges the old versions on demand (that is, only if the time range is changed) completely or partially abandoned, i. from the owner assignment be removed (which makes them "common property") Versions that are not completed are handled by default as would they atomically unlock by using the actual_activity_validid (for non-transactional Submodels may also be released with act_freeze) and immediately set again at the new time location. That way is made sure that address information is at get or other operations always designate a unique version of a lock and the "inheriting" of the timestamp from the container to the hosted Operations instances is.

Compared to read_lock, the direct specification of a set (or list or array) of quadruples causal is added here. A quadruple has the form (adr_search, min_act, stable, direct). The value of adr_search specifies the location where the causal read or write locks are located. By including min_act, stable and direct in the quadruples, these properties can be set individually for the functional dependencies in each address range ¹⁶⁴ .

If a lock container with actuality degree act_close already exists in the search area, whose already existing causal dependencies represent a compatible superset to the required ones and which itself does not take part in later causal dependencies, then this container may be reopened instead of recreating a container. This optimization does not need to be supported in every implementation; act_close may also be treated as act_freeze on unlock.
unlock (nest, mandate, adr_search, act)

Opposite the earlier Version from section 3.3.5 comes here only the actuality degree act to which the locks to be released are to be set. It is possible, Locks several times gradually to ever higher levels of actuality to set, allowing a correct bracketing of lock / unlock pairs no longer needs to be respected.

urges an (asynchronous) return an unfinished lock. In addition to the return of speculatively enlarged address ranges can be over time_need also the reduction of time intervals in distributed systems perform consistently, if the convention prevails that unfinished locks only from their owner may be reduced.

7.8 Simulation of some Transaction strategies

Different variants of classical ACID transactions are simulated by the just presented lock operations in the following way:
Each individual read and write operation, which refers to a not yet curled address range, is preceded by locks. If necessary, read-locks are upgraded to write-locks so that the same lock-type is requested on the same address range, but at the same time interval. Otherwise once requested locks are not released until the end of the transaction (2-phase-locking).

The causal dependencies are based on the basic idea of the Herbrand semantics of syntactic transaction models [VGH93] always set so that all address ranges ever handled by a transaction in the Write locks must be specified.

At the Commit all set locks atomically by unlocking on the whole Address space (i.e., one chooses adr_search = (0, ∞)) with at least act = act_safe completed (if the D property by ACID expressly is required at each commit); Rollback is instead to select act = act_invalid.

at The following simulations of conventional transactions will always be stable = true and direct = true. The individual transaction variants differ by what time intervals and min_act values each time you set the locks are selected.

7.8.1 Timestamp Ordering Protocols

Simulation of Multiversion Timestamp Orderirig (MVTO) from the database literature [VGH93] ensures serializability by considering all operations of a transaction as having the same timestamp; This creates a virtual temporal total order of all operations which corresponds exactly to the serialization order. Databases also need the ability to manage multiple versions of objects (sometimes called time-domain addressing [GR93]). The timestamp is once determined at the beginning of the transaction or at the first access so that each transaction has a unique timestamp that is never changed.

The Simulation of read-write transactions by multiversion nests is relatively simple: the locks are set with time_set = (start, 0) and act = act_tmp, starting once at the beginning of the Transaction clearly assigned timestamp means.

Read-only transactions can be simulated by setting a single read-lock on the entire address range adr_set = (0, ∞) at the beginning of the transaction, deviating from the general strategy described above, so that the subsequent read operations are no longer must be individually secured by read locks. Such a read-lock, which covers the entire address range, creates a snapshot ^{165 of} the entire nest.

There also with read-write transactions all read-locks with the same time stamp can be set here, the individual Replace read locks with a snapshot lock; while writing then individual parts of the snapshot lock are perforated and upgraded to write-locks.

7.8.2 Strict 2-phase locking

at the simulation of classical 2-phase locks [VGH93] becomes the multiversion behavior not used at all. Read and write locks are on the time interval time_set = (now, ∞) where now the strictly monotonously progressive current real time when called. Granting the lock will this Time interval on the grant date downsized, allowing subsequent write locks on the timeline Find a place. In the quads of the write-locks is min_act = act_freeze made sure that at most each time a single incomplete write lock on overlapping Addresses exists.

7.8.3 Other types of Serializability or consistency models

There are also several write locks possible at the same real time, which may not just overlap on the virtual timeline. You could call that multiversion locking. The ability to lock overlapping address ranges at the same real time, however, goes beyond the term "multiversion concurrency control ^166" [HR01] or the term multiversion conflict serializability [VGH93], which may include time domain locking a good name at least for the English-language literature.

Of the generalized serialization term from [Vid87], both the conflict as well as the MVTO serializability as a special case contains might also simulate themselves through the nest interface presented here to let. This also applies to Protocol families like MVSGT (multiversions serialization graph tester), which can be realized as concrete strategies in building blocks.

nested Transactions can be realized by building blocks, the groups of change operations to pass outwards through accumulated lock operations and if necessary, the actuality levels transform into other values.

Through "skipping" causal dependencies, softening of the Herbrand semantics, and variation of the min_act, stable, and direct parameters, further concepts of serializability can be formed whose systematic investigation is left to further work For example, if speculative magnified lock areas can only be bought with "skipping" causal dependencies or less up-to-dateness ¹⁶⁷ and much more

By deliberately releasing a few locks before the end of the transaction, any mixing paradigm can be realized between perfect transactional isolation and mutual exclusion ¹⁶⁸ . The mutual exclusion used until now in operating systems is supplemented orthogonally by the concept of actuality levels, so that a subsequent reset of failed calculations (which can be interwoven with computations of other mandates non-serializable) is possible.

7.8.4 Automatic re-evaluation

The Idea consists in the containers (occasionally or partially also in the stored causal dependencies) not (only) the Results of consumer-generated access operations accommodate, but (additionally) their calculation rule.

Thereby you can recompute the hosted access operations if subsequent changes in one of the causal preceding container or subsequent Pushing write locks into stable causal dependency relationships be allowed, thereby reducing the causal dependencies on the new versions amended become. With such changes is merely a recalculation of the container content of all transitive causally dependent Container triggered; the container itself and its position in the space-time level is preserved.

A Specification of the calculation rule can be made by introducing a appropriate interpreter and an interpreter language, from the program pieces be made known by means of an operation download (e.g. Addition of number values or calculation of a sum). Downloading of executable Machine code is also possible in principle, but has disadvantages in safety (for their solution You can have special conventions for those active during the evaluation Introduce protection zones).

In both cases should be possible all consumers their transfer operations to change the data and / or address mapping from nests through download operations to replace non-reevaluable containers can not stop this procedure or incorrectly.

A simulation inheritance through genericity

To demonstrate that extension genericity can be expressed using Parametric Genericity, we simulate the core idea of object-oriented inheritance through preprocessor macros of language C:

Following these general declarations, a one-time specification of two classes A and B follows by means of macro definitions:

Using the Unix commands gcc -Einerbung.c | grep -v '^ #' | indent -bad -bap | indent -kr results in the following expanded source code:

B example problems of object orientation

An example in which the co-inheritance of data structures or representations can lead to a combinatorial explosion of classes:
The extension of an abstract base class G should take place in two different independent ways. This can be done relatively easily by two different derived abstract base classes A and B. From each of the two abstract base classes we derive different concrete classes A ₁ , ..., A _n and B ₁ , ... B _m whose functionality is needed in each case. Now the requirement is added that the union of both interfaces is also needed. At the level of abstract base classes, this is very easy to accomplish by another base class C, which gets its interface from A and B through multiple inheritance. However, this means for the concrete classes C _ij derived from them that the entire Cartesian product of n · m derived classes is now suitable and possibly to be implemented. Even if no new functionality should be added by means of overridden method implementations, this leads to a combinatory explosion of the class names and to a bloat of the entire system. In my opinion, this problem often crops up in practice without being recognized.

• 1. Die bisherigen Attribute waren Mitglieder der alten Objektinstanz-Repräsentation; von der neuen Repräsentation werden sie entweder indirekt adressiert oder sie werden nochmals eingebettet. Dadurch wird Platz verschwendet.
• 2. Die gemeinsame Oberklasse G kann Attribute enthalten, die bei der Mehrfachvererbung nur einmal gemeinsam instantiiert werden sollen.
• 3. Der Namensraum wird nach wie vor durch n·m verschiedene Klassennamen verschmutzt.

There is an often-working solution to this problem without having to leave the object-oriented paradigm. The implementation of a derived class C _ij should not be done by multiple inheritance, but by container instances c _ij ∈ C _ij , each containing two instances a _i ∈ A _i and b _j ∈ B _j (in the form of a has-a relationship instead an is-a relationship). One can also call C _ij a proxy class. However, this entails the following difficulties:

• 1. The previous attributes were members of the old object instance representation; they are either indirectly addressed by the new representation or re-embedded. This wastes space.
• 2. The common superclass G can contain attributes that are to be instantiated only once in multiple inheritance.
• 3. The namespace is still polluted by n · m different class names.

The first problem is annoying endangered but the correctness is not. To solve the second problem can one gets a third component g ∈ G into the container instance. The third problem can not be avoided and charged in the cheapest Case only the compiler.

It However, there is another solution: you lead a class C containing the sum of the interfaces and otherwise only acts as a trivial container, which is the actual implementation in G, A and B calls (which approximately doubles the interface overhead). However, in the object orientation this ultimately operates same kind of embedding of sub-object instances, as in "conventional" programming paradigms has always been handled; it will only be an additional expense driven by duplication of interfaces to the object-oriented Rescue paradigm using multiple inheritance at the interface to be able to. It raises the question of whether the conceptually through multiple inheritance resulting interface C, but their implementation no (Multiple) inheritance is used, really needed, or whether the through Use of A and B as a substitute for C not the bottom line is easier. Independently of I see that for the object orientation is not essential paradigm of inheritance more than actually used, and I ask the question if it is not right from the start should have omitted can.

This in my opinion does not mean that automated derivation of object-oriented data schemas from class schemas in general is useless, because there are very application fields where the automatic Derivation of recurring operations streamlined.

I I'm of the opinion that object orientation is often useful Scheme for designing interfaces; but that one unreflective Implementation of this scheme into concrete data structures costly or even dangerous Can be, as the usual offered data representations not for the task needs to be optimal.

On methodically, the problem described also seems to me to be in this to lay that object-oriented design thinking often on Bending and Breaking tries to solve everything by extension genericity. The presented here Problem setting, however, fits much better with compositional genericity. This example is therefore another argument for that of I favored the priority of compositional generosity over enlargement genericity.

C approaches to Avoidance of races

• 1. Make sure there are always enough resources and withdrawal is therefore never necessary. Unfortunately, that speaks reality often against, because resources are always finite and according to a quasi-natural law often not sufficient to meet the needs. If the need is limited or if you are already in the process of issuing resource limits introduces (e.g. quota), u.U. refrain from reclaiming mechanisms. Also falls into this category e.g. the exchange of equivalent resources, in which as well a recovery can be excluded in the future. In the sense of the ownership / ownership model (Section 5.1) this means that real property (not just mere possession) is transferred will never be reclaimed can be.
• 2. One demands that possession in principle only to hierarchically lower-level instances and only for the duration may be disclosed to the processing of an operation; in order to that would be Concept of logical IO is no longer used and the model is restricted.
• 3. It is only permissible to return such sub-possession to higher authorities, which has already been assigned once by the same higher authority as principal property to the lower one (transitive return delivery of sub-objects). In reality, the sub-possession always belongs to the higher authority; a recovery by the main owner is classified as unauthorized and not executed or even ver examined. This construction expands the model compared to 2 without introducing serious disadvantages; therefore, I prefer it over 2. However, I still see it as relatively limited, especially for distributed systems and network operating system applications. On the conceptual level, it seems to me that there is a mix-up of labels, because in reality there is no real delegation of power over ownership.
• 4. One gives possession to higher ones Instances (possibly also to lower instances) basically only on limited (real) time, within which the resource either returned or the rental period will be extended got to; the Time limit is calculated so that a lapse of the loan date does not take place in normal operation. After this model it is the Duty of each borrower, either for timely return or for extension of time (similar to the lending procedure of a university library). When the time limit is exceeded is wrong, then there is a misconduct in this sense, and the Resources can e.g. be withdrawn automatically. However, this withdrawal has again the character of an asynchronous signal, i. it does not change anything the principle of return, only on the trigger. This model is particularly suitable for some distributed applications Systems, as a timely return or extension can also be interpreted as a failure of an instance on the then e.g. with automatic withdrawal of resource ownership and redistribution is reacted; if the instance had not actually failed, but only the communication connection, then the affected entity "knows" after expiration the deadline that they are renewing did not make it on time and that she is no longer a "legitimate" owner.
• 5. Ownership of higher Instances happens exclusively under the full control of the lower instance, which completely determine can what happens to it. This, however, also makes the hierarchy model in the regular Operation turned upside down; it would ask the question if it still has an authorization. Also the suitability for distributed Systems seems to me the most doubtful.

none these approaches seems appropriate for me, the race problem (Chapter 5) from the To create that world by that no new problems arise and that requirements of distributed Sufficiently considered systems become. An evaluation of which of these problems is more important Consider, depending on the position of the evaluator and according to requirements different from the system (for example, I see for extremely safety-critical applications model advantages 3). It is basically possible, a concrete building block hierarchy within the here presented To design architecture so that notify _ * operations and whose races are avoided; I see that as desirable where avoidance is readily possible and only low cost caused. However, I see little chance of racing in one distributed system so as to avoid any performance disadvantages or dependencies from the functionality central instances arise.

literature

• [AB86] ARCHIBALD, JAMES and JEAN-LOUP BAER: Cache Coherence Protocols: Evaluation Using a Multiprocessor Simulation Model. Transactions on Computer Systems, 4 (4): 273-298, 1986.
• [Ant90] ANTONOV, VADIM G .: A Regular Architecture for Operating System. Operating System Reviews, 24 (3): 22-39, 1990.
• [ASS96] ASSENMACHER, HOLGER: An architecture concept to the design flexible operating systems. Dissertation University of Kaiserslautern, 1996th
• [AW94] ATTIYA, HAGIT and JENNIFER L. WELCH: Sequential Consistency versus linearizability. Transactions on Computer Systems, 12 (2): 91-122, 1994th
• [B ⁺ 90] BERSHAD, BRIAN N. and OTHERS: Lightweight Remote Procedure Call. Transactions on Computer Systems, 8 (1): 37-5, 1990.
• [B ⁺ 95] BERSHAD, BAIAN N., and OTHERS: SPIN - An Extensible Microkernel for Application-specific Operating System Services. Operating System Reviews, 29 (1): 74-77, 1995.
• [Bac86] BACH, MAURICE J .: The Design of the UNIX Operating System. Prentice Hall, 1986. [BHG87] AMBER, PILIP A., VASSOS HADZILACOS and NATHAN GOODMAN: Concurrency Control and Recovery in Database System. Addison-Wesley, 1987.
• [BN84] BIRRELL, ANDREW D. and BRUCE JAY NELSON: Implementing Remote Procedure Calls. Transactions on Computer Systems, 2 (1): 39-56, 1984th
• [BPS81] BELADY, L.A., R.P. PARMELEE and C.A. SCALZI: The IBM History of Memory Management Technology. IBM Journal of Research and Development, 25 (5): 491-503, 1981.
• [BR76] BLEVINS, PARKER R. and C.V. RAMAMOORTHY: Aspects of a Dynamically Adaptive Operating System. Transactions on Computers, 25 (7): 713-725, 1976.
• [BS75] BERNSTEIN, ARTHUR 7th and PAUL SIEGEL: A Computer Architecture for Level Structured Systems. Transactions on Computers, 24 (8): 785-893, 1975th
• [BS96] BRUSTOLONI, JOSE CARLOS, and PETER STEENKISTE: Effects of Buffering Semantics on I / O Performance. OSDI, pages 277-291, 1996th
• [BS02] BROY, MANFRED and JOHANNES SIEDERSLEBEN: object-oriented Programming and software development. Computer Science Spectrum, 25 (1): 3-11, Of 2002.
• [BSS91] BIRMAN, KENNETH, ANDRE SCHIPER and PAT STEPHENSON: Lightweight Causal and Atomic Group Multicast. Transactions on Computer Systems, 9 (3): 272-314, 1991.
• [C ⁺ 94] CHASE, JEFFREY S. and OTHERS: Sharing and Protection in a Single-Address Space Operating System. Transactions on Computer Systems, 12 (4): 271-307, 1994.
• [Che87] CHERITON, DAVID R .: UIO: A Uniform I / O System Interface for Distributed Systems. Transactions on Computer Systems, 5 (1): 126, 1987th
• [CJ75] COHEN, ELLIS, and DAVID JEFFERSON: Protection in the Hydra Operating System. Symposium on Operating System Principles, pages 141-160, 1975.
• [CL85] CHANDY, K. MANI and LESLIE LAMPORT: Distributed Snapshots: Determining Global States of Distributed Systems. Transactions on Computer Systems, 3 (1): 63-75, 1985.
• [Cla85] CLARK, DAVID D .: The Structuring of Systems Using Upcalls. Symposium on Operating System Principles, pages 171-180, 1985.
• [CLG ⁺ 93] CHEN, PETER M., EDWARD K. LEE, GARTH GIBSON, RANDY H. KATZ, and DAVID A. PATTERSON: RAID: High-Performance, Reliable Secondary Storage. Computing Surveys, 26 (2): 145-185, 1993.
• [CW85] CARDELLI, LUCA and PETER WEGNER: On Understanding Types, Data Abstraction, and Polymorphism. Computing Surveys, 17 (4): 471-522, 1985th
• [Dat95] DATE, C.J .: An Introduction to Database Systems. Addison Wesley, 1995.
• [Den68] DENNING, PETER J .: The Working Set Model for Program Behavior. CACM, 11 (5): 323-333, 1968.
• [Den71] DENNING, PETER J .: Virtual Memory. Computing Surveys, 2 (3): 153 to 189.1971.
• [DGMS85] DAVIDSON, SUSAN B., HECTOR GARCIA-MOLINA and DALE SKEEN: Consistency in partitioned networks. Computing Surveys, 17 (3): 341-370, 1985th
• [DH66] DENNIS, JACK B. and EARL C. VAN HORN: Programming Semantics for Multiprogrammed Computations. CACM, 9 (3): 143-155, 1966.
• [Dij68] DIJKSTRA, EDSGER W .: The Structure of the "THE" Multiprogramming System. CACM, 11 (5): 341-346, 1968.
• [Dij71] DIJKSTRA, E.W .: Hierarchical Ordering of Sequential Processes. Acta Informatica, 1: 115-138, 1971.
• [dJ93] JONGE, WILL DE: The Logical Disk: A New Approach to Improving File Systems. Symposium on Operating System Principles, Pages 15-28, 1993.
• [Doe96] DOEPPNER, THOMAS W .: Distributed File Systems and Distributed Memory. Computing Surveys, 28 (1): 229-231, 1996.
• [DS72] DENNING, PETER J. and STUART C. SCHWARTZ: Properties of the Working Set Model. CACM, 15 (3): 191-198, 1972.
• [EKO95] ENGLER, DAWSON R., M. FRANS KAASHOEK and JAMES O'TOOLE: Exokernel: An Operating System Architecture for Application-Level Resource Management. Symposium on Operating System Principles, pages 251-266, 1995th
• [Elmbe] ELMAGARMID, AHMED S .: Database Transaction Models For Advanced Applications. Morgan Kaufmann, without year.
• [EN95] ELMASRI, RAMEZ and SHAMKANT B. NAVATHE: Fundamentals of Database Systems. Addison Wesley, 1995.
• [Esk96] ESKICIOGLU, M. RASIT: A Comprehensive Bibliography of Distributed shared memory. Operating System Reviews, 30 (1): 71-96, 1996th
• [Fie88] FIELD, ANTHONY J .: Functional Programming. Addison-Wesley, 1988th
• [PHOTHERINGHAM, JOHN: Dynamic Storage Allocation in the Atlas Computer, Including an Automatic Use of Backing Store. CACM, 4 (10): 43536, 1961.
• [GC94] GOODHEART, BERNY, and JAMES COX: The Magic Garden Explained - The Internals of UNIX System V Release 4. Prentice Hall, 1994.
• [GR93] GRAY, JIM and ANDREAS REUTER: Transaction Processing: Concepts and Techniques. Morgan Kaufmann, 1993.
• [Hab69] HABERMANN, A. N .: Prevention of System Deadlocks. CACM, 12 (7): 373-385, 1969.
• [Haj00] HAJJI, FARID: Perl - Introduction, Applications, Reference. Addison Wesley, 2000.
• [Han70] HANSEN, PER BRINCH: The Nucleus of a Multiprogramming System. CACM, 13 (4): 238-250, 1970.
• [Han73] HANSEN, PER BRINCH: Concurrent Programming Concepts. Computing Surveys, 5 (4): 223-245, 1973.
• [Hoa74] HOARE, C.A.R .: Monitors: An Operating System Structuring Concept. CACM, 17 (10): 549-557, 1974.
• [Hoa78] HOARE, C.A.R .: Communicating Sequential Processes. CACM, 21 (8): 666-677, 1978.
• [HP94] HEIDEMANN, JOHN S. and GERALD J. POPEK: File System Development with Stackable Layers. Transactions on Computer Systems, 12 (1): 58-89, 1994.
• [HP95] HEIDEMANN, JOHN and GERALD POPEK: Performance of Cache Coherence in Stackable Filing. Symposium on Operating System Principles, Pages 127-142, 1995.
• [HR83] HARDENERS, THEO and ANDREAS REUTER: Principles of Transaction-Oriented Database Recovery. Computing Surveys, 15 (4): 287-317, 1983.
• [HR01] HARDENERS, THEO and ERHARD RAHM: Database Systems Concepts and Techniques of Implementation. Springer-Verlag, 2nd edition edition, 2001.
• [Hur] The GNU Hurd - GNU Project - Free Software Foundation (FSF). http://www.gnu.org/software/hurd/hurd.html.
• [HW90] HERLIHY, MAURICE P. and JEANNETTE M. WING: Linearizability: A Correctness Condition for Concurrent Objects. Transactions on Programming Languages and Systems, 12 (3): 46392, 1990.
• [Jef85] JEFFERSON, DAVID R .: Virtual Time. Transactions on Programming Languages and Systems, 7 (3): 40425, 1985.
• [JH02] JOHN, STEFAN and STEPHAN HERRMANN: What, please, does object orientation mean? Computer Science Spectrum, 25 (4): 266-275, 2002.
• [Jon80] JONES, ANITA K .: Capability Architecture Revisited. Operating System Reviews, 14 (3): 33-35, 1980.
• [Jür73] JÜRGENS, JÜRN: Synchronization parallel processes based on states. Doctoral thesis, Technical university Munich, 1,973th
• [K ⁺ 81] KAHN, KEVIN C., and OTHERS: iMAX: A Multiprocessor Operating System for an Object-Based Computer. Symposium on Operating System Principles, pages 127-136, 1981.
• [K ⁺ 91] KARLIN, A. and OTHERS: Empirical Studies of Competitive Spinning for a Shared-Memory Multiprocessor. Symposium on Operating System Principles, pages 41-55, 1991.
• [K ⁺ 97] KAASHOEK, M. FRANS, and OTHERS: Application Performance and Flexibility on Exokernel Systems. Symposium on Operating System Principles, pages 52-65, 1997.
• [KE95] KLEIMAN, STEVE and JOE EYKHOLT: Interrupts as Threads. Operating System Reviews, 29 (2): 21-26, 1995.
• [Knu94] KNUTH, DONALD E .: The T _E Xbook. Addison Wesley, 1994.
• [LA93] LIM, BENG-HONG and ANANT AGARWAL: Waiting Algorithms for Synchronization in Large-Scale Multiprocessors. Transactions on Computer Systems, 11 (3): 253-294, 1993.
• [Lag78] LAGALLY, K .: Synchronization in a Layered System. In: FLYNN, M.J. and OTHERS (Editor): Operating Systems, An Advanced Course, Volume 60 of the series Lecture Notes in Computer Science, pages 253-281. Springer-Verlag, 1978.
• [Lam74] LAMPORT, LESLIE: A New Solution to Dijkstra's Concurrent Programming Problem. CACM, 17 (8): 453-455; 1974th
• [Lam78] LAMPORT, LESLIE: Time, Clocks, and the Ordering of Events in a Distributed System. CACM, 21 (7): 558-565, 1978.
• [Lam84] LAMPORT, LESLIE: Using Time Instead of Timeout for Fault-Tolerant Distributed Systems. Transactions on Programming Languages and Systems, 6 (2): 254-280, 1984.
• [Lan81] LANDWEHR, CARL E .: Formal Models for Computer Security. Computing Surveys, 13 (3): 247-278, 1981.
• [LCC ⁺ 75] LEVIN, R., E. COHEN, W. CORWIN, F. POLLACK and W. WULF: Policy / Mechanism Separation in Hydra. Symposium on Operating System Principles, pages 132-140, 1975.
• [LH89] LI, KAI, and PAUL HUDAK: Memory Coherence in Shared Virtual Memory Systems. Transactions on Computer Systems, 7 (4): 321-359, 1989th
• [Lie95a] LIEDTKE, JOCHEN: Address Space Sparsity and Fine Granularity. Operating System Reviews, 29 (1): 87-90, 1995.
• [Lie95b] LIEDTKE, JOCHEN: On μ-Kernel-Construction. Symposium on Operating System Principles, pages 237-250, 1995.
• [Lio96] LIONS, JOHN: Lions' Commentary on UNIX 6th Edition with Source Code. Peer-to-peer communications, 1996th
• [LS87] LOCKEMANN, P.C. and J.W. SCHMIDT: Database Manual. Springer-Verlag, 1987.
• [LS94] LIN, TEIN-HSIANG and KANG G. SHIN: To Optimal Retry Policy Based on Fault Classification. Transactions on Computers, 43 (9): 1014-1025, 1994th
• [McK96] MCKUSICK, MARSHALL KIRK: Secondary Storage and Filesystems. Computing Surveys, 28 (1): 217-219, 1996.
• [Mey88] MEYER, BETRAND: Object-oriented software development. Prentice Hall, 1988.
• [MJLF84] MCKUSICK, MARSHALL K., WILLIAM N. JOY, SAMUEL J. LEFFLER and ROBERT S. FABRY: A Fast File System for UNIX. Transactions on Computer Systems, 2 (3): 181-197, 1984.
• [MP81] MILLER, BARTON and DAVID PRESOTTO: XOS: An Operating System for the X-Tree Architecture. Operating System Reviews, 15 (2): 21-32, 1,981th
• [NW74] NEEDHAM, R.M. and M.V. WILKES: Domains of protection and the management of processes. Computer Journal, 17 (2): 117-120, 1974th
• [NW77] NEEDHAM, R.M. and R.D. H. WALKER: The Cambridge CAP Computer and its protection system. Symposium on Operating System Principles, pages 1-10, 1977.
• [OpL] Opportunistic Locks. http: //msdn.microsoft.com/library/default.asp? url = / library / en-us / fileio% / base / opportunistic_locks.asp http://msdn.microsoft.com/library/default.asp?url=/library/ en-us / fileio% / base / opportunistic_lock_examples.asp http://msdn.microsoft.com/library/default.asp?url=/library/ en-us / fileio% / base / how_to_request_an_opportunistic_lock.asp http://msdn.microsoft.com/library/default.asp?url=/library/ en-us / fileio% / base / breaking_opportunistic_locks.asp.
• [Opl65] OPLER, ASCHER: Procedure-Oriented Language Statements to Facilitate Parallel Processing. CACM, 8 (5): 306-307, 1965.
• [Org72] ORGANICK, ELLIOT I .: The Multics System: An Examination of Its Structure. MIT Press, 1972.
• [Par72] PARNAS, D.L .: On the Criteria To Be Used in Decomposing Systems into Modules. CACM, 15 (12): 1053-1058, 1972.
• [Par78] PARNAS, DAVID L .: The Non-Problem of Nested Monitor Calls. Operating System Reviews, 12 (1): 12-18, 1978.
• [PC75] PRUITT, J.L. and W.W. CASE: Architecture of a Real Time Operating System. Symposium on Operating System Principles, Pages 51-59, 1975.
• [PDZ99] PAI, VIVEK S., PETER DRUSCHEL and WILLY ZWAENEPOEL: IO-liter A Unified UO Buffering and Caching System. OSDI, pages 15-28, 1999.
• [PDZ00] PAI, VIVEK S., PETER DRUSCHEL and WILLY ZWAENEPOEL: IO-liter A Unified UO Buffering and Caching System. Transactions on Computer Systems, 18 (1): 37-6, 2000.
• [RK79] REED, DAVID P. and RAJENDRA K. KANODIA: Synchronization with event counts and sequencers. CACM, 22 (2): 115-123, 1979.
• [R091] ROSENBLUM, MENDEL and JOHN K. OUSTERHOUT: The Design and the implementation of a log-structured file system. symposium on Operating System Principles, pages 1-15, 1991.
• [Ros94] ROSCOE, TIMOTHY: Linkage in the Memesis Single Address Space Operating System. Operating System Reviews, 28 (4): 48-55, 1994.
• [RT74] RITCHIE, DENNIS M. and KEN THOMPSON: The UNIX Time Sharing System. CACM, 17 (7): 365-375, 1974.
• [Smi88] SMITH, JONATHAN M .: A Survey of Process Migration Mechanisms. Operating System Reviews, 22 (3): 280, 1988.
• [Str78] STROUSTRUP, BJARNE: On Unifying Module Interfaces. operating System Reviews, 12 (1): 90-98, 1978.
• [Szy98] SZYPERSKI, CLEMENS: Component Software. Addison-Wesley, 1998th
• [T ⁺ 90] TANENBAUM, ANDREW S. and OTHERS: Experiences with the Amoeba Distributed Operating System. CACM, 33 (12): 47-63, 1990.
• [TA90] TAY, B.H. and A.L. ANANDA: A Survey of Remote Procedure Calls. Operating System Reviews, 24 (3): 68-79, 1990.
• [Tho96] THOMPSON, SIMON: Haskell: The Crafi of Functional Programming. Addison-Wesley, 1996.
• [TL93] THEKKATH, CHANDRAMOHAN A. and HENRY M. LEVY: Limits to Low-latency communication on high-speed networks. Transactions on Computer Systems, 11 (2): 179-203, 1993.
• [TSF90] TAM, MING-CHIT, JONATHAN M. SMITH and DAVID J. FARBER: A Taxonomy-Based Comparison of Multiple Distributed Shared Memory System. Operating System Reviews, 24 (3): 40-67, 1990.
• [Vah96] VAHALIA, URESH: UNIX Internals. Prentice Hall, 1996.
• [VGH93] VOSSEN, GOTTFRIED and MARGRET GROS-HARDT: Basics the transaction processing. Addison-Wesley, 1993.
• [Vid87] VIDYASANKAR, K .: Generalized Theory of Serializability. Acta Informatica, 24: 105-119, 1987.
• [Y ⁺ 90] YOKOTE, YASUHIKO, and OTHERS: The Muse Object Architecture: A New Operating Systems Structuring Concept. Operating System Reviews, 25 (2): 226, 1990.

Remarks

¹ The usual way is to capture requirements before starting any design work. If this is not possible, one could succumb to the temptation to simply ignore requirements. This can result in serious disadvantages. It is therefore not my intention to abolish a requirement analysis, but this in later design phases, in particular the detailed design concrete block types, to move.

² This effect is not limited to object-oriented systems; It seems to me to be a sociological and psychological problem in any software development with many involved, and therefore should be relevant for the architecture presented here beyond a certain size (Conway's Law: "Systems mirror the structure of organizations producing them"). However, the object-oriented paradigm is sometimes taught as if broadening existing interfaces is a panacea to the problem of any change in requirements.This often subliminal attitudes, along with the ease of handling extensibility facilitated by the object-oriented languages, can easily lead to the proliferation of class hierarchies (Or in conventional designs for flanging "balconies") and thus avoidable reduplication of implemented functionality.

³ There may also be more than the varieties of generosity examined in this work.

⁴ In particular, compared to the possibilities of macro-processor text replacement, Meyer's concept of genericity appears to be much narrower than the term "parametric genericity".

⁵ Meyer states in Chapters 6 and 19 that (parametric) genericity without type testing would be pointless. However, this contradicts, among others, the Lisp tradition since the 1960s, in which parametric genericity was used without automated type tests. If you want to use the concept of parametric polymorphism in such languages as the original form of Lisp, you just have to make the type checks "by hand" if necessary, perhaps because of the misunderstanding that the naked term genericity is often synonymous with the equivalent This limited use obscures the much wider possibilities of genericity in the sense of redundancy reduction mechanisms.

⁶ Some examples are intended to illustrate briefly that despite their lesser security against accidental misuse, macro-processors can perform some useful applications of parametric genericity that are not easily simulated by parametric polymorphism:
For example, you can use macro processors to sort the fields of structures (records or class members) alphabetically by name or by combined keys such as (type, name). It is possible to subject the names of the members to a specific naming scheme or to check compliance with a particular naming scheme, for example by having the names of all members of a class A of the form A_ *. In statically typed languages such as Eiffel or C ++, statically evaluable iterators can be defined via class members, which otherwise can only be implemented generically in non-typed languages such as Smalltalk. By means of sufficiently powerful macro languages such as TeX, which are of the type Chomsky-0, one can theoretically even operate automatic type inference between classes and automatically extract abstract base classes from a given class schema. Such techniques could, for example, serve to discover previously undiscovered redundancy in large software projects.

⁷ Excessive of genericity can also increase redundancy, impair the transparency of software, degrade performance, and therefore lead to negative effects. An objectively exact assessment and weighing of the employment agencies seems difficult and is therefore often subject to the subjective assessment of the respective designer.

⁸ This does not contradict the seemingly inverse statement of Meyer's analysis in [Mey88, Section 19.3]. Meyer uses the notion of genericity synonymous with an expression of parametric polymorphism, as occurs specifically in Ada. By contrast, I understand parametric genericity to be a much more general concept, and genericity is an even more general category of thinking. One has to keep these different concepts in mind when comparing the statements with each other. However, the example presented here supports the concept formation proposed here.

⁹ The hierarchical modularization of file systems presented in [HP94] uses some of the concepts presented here, but is not limited to the functionality of file systems and uses their more elaborate interfaces (especially for the management of file system subtrees), but is also inherently based on conventional file systems. Concepts and abstractions such as vnodes, vno de-operations and vfs, which play no role in the present work.

¹⁰ Also universal genericity can be expressed by parametric genericity. The distinction between the different types of genericity is therefore ultimately only a human understanding approach that should make a certain way of thinking communicable in the design.

¹¹ The problem with a more formal version of the concept of universal genericity is what should be understood by simply. If you allow "complicated" simulations, then you can hide significant parts of the functionality in the figure on the concept to be simulated instead of solving it in the basic concept used.The "simplicity" of a simulation can be formalized in several different ways; Since this discussion is only about categories of thinking during the design phase, I have renounced formal versions of all of these terms.

¹² Exceptions to this rule only exist in investigations of concrete alternative mechanisms for specific well-defined subproblems.

¹³ In the seemingly unnoticed article [Ant90], Antonov describes, unfortunately in partly very difficult to understand and sometimes not unambiguously interpretable English, a "regular architecture" which, despite its formal presentation, comes very close to the core idea of the architecture presented here However, there are further major differences in detail, such as the huge number of interface functions, the instantiation mechanisms, the built-in protection mechanisms, and possibly the number of interoperable generators "Outputs" per "block" (in all examples there is always only one output, a grammatically clear explicit reference to several "outputs" I could not find). Furthermore, Antonov lacks the replacement of file systems introduced here by dynamic hierarchical instantiation of building blocks; a distinction between different operating modes or operating models is also not apparent.

¹⁴ An exception is [Str78], where Stroustrup points out the independence and interchangeability of the implementation paradigms from the module interfaces, thus further understanding the architectural notion. Unfortunately, this basic article seems to have received little attention in operating system literature, as decades later the use of fixed implementation paradigms still seems to be state of the art.

¹⁵ This applies only to design decisions that are left open within the architecture presented here and therefore can be parameterized; However, at the level of the meta-architecture itself, I also make firm decisions that in principle (as with previous architectures) are subject to the above-mentioned criticism and in individual cases require further evaluation and, if necessary, a revision.

^{16 In practice,} this term is usually associated with object orientation (cf., eg, [JH02, p. 273]: "Frameworks are complex, partial programs whose instantiation to an application without inheritance would be inconceivable"), right through to designation Thus, the term framework would fit well with the architecture presented here, if it were not already restricted in the manner cited, and it might make sense to expand on that term However, a broad consensus should be reached on this.

¹⁷ On the current discourse between Broy / Sindersleben [BS02] and Jähnichen / Herrman [JH02] on the nature, advantages and disadvantages of object orientation, in particular the connection between components and object orientation, the present work can contribute to broadening the perspective. One could simply call the architecture presented here a component architecture, although it does not necessarily build on the object orientation and thus deviates from the prevailing opinion in this regard. As shown in section 6.2, object-oriented inheritance is made possible by the architecture presented here, but not imposed as a mandatory requirement. In the examples in Chapter 4, I have emphasized the importance of realizing the basic functionality of an operating system only with the help of generosity of composition and avoiding extensiveness of generosity almost completely. Thus, there is an example that realizes a component architecture without a fixed link to a fundamental idea of object orientation (no matter whether you call it "inheritance" or a special case of "delegation"). Thus, sufficient substance has been put forward to support the thesis that component architectures are largely orthogonal to the application of object-oriented Ent throwing methods can be considered. However, such consideration depends on the definition of "object orientation," and depending on the taste or origin of a particular school, one can define the terms in such a way that object orientation is a generic term, including component architectures as a complementary application of the principle of compositional Genericity fall, or vice versa, or that two mutually orthogonal concepts arise.I argue for reasons of methodological thrift for the third variant.

¹⁸ Cf. [Szy98, Section 4.1.8]. The supposed phenomenon of "maximizing reuse minimizes use" seems to me to be based on the implicit assumption of extension-generation as a maximization strategy across component boundaries, a phenomenon that is reversed by the concept of generational generationality and universal genericity.

¹⁹ Szyperski [Szy98] emphasizes several times (Sections 1.5, 4.1.1) that the instantiation of components would be pointless because of statelessness. In contrast to this, multiple instances of you _ * blocks, for example, make perfect sense, since the position in a block hierachy or the wiring context definitely matters.

²⁰ A similar view is made by Parnas in [Par78].

²¹ Independent of this, again, are the waiting strategies of several processes willing to enter such as the FIFO strategy (as an interesting implementation example, see [RK79]).

²² In practice, this intent is not always consistent, especially in larger projects involving many stakeholders with different interests. For example, one interest group might prefer the programming language Ada, the other the language C (Arguments for the respective positions are well known: Without a doubt, Ada is the safer, more productive and less serviceable language, but the majority of already existing and tested software is written in C or C ++, which must be compatible). In principle, the architecture presented here can not only be implemented uniformly in one of the two languages, but also block by block in arbitrary mixtures, provided the calling conventions of the respective languages and compilers are compatible with one another. Since this can increase not only the redundancy, but also the integration effort and possible sources of error, this should be avoided as far as possible, but in any case very well thought out and justified.

²³ As [Mey88] and many other authors note, the main arguments about structuring criteria are mainly along the demarcation lines "structuring by data" versus "structuring by control flow" (see [Par72]). By contrast, the structuring of areas of responsibility that I propagate takes on a higher-level perspective: responsibility is almost always linked to data structuring and only rarely to control flows. The level of abstraction, however, is decoupled from concrete data structures: at a high level of abstraction, responsibility can extend to sets of data structures, but at the other extreme, they can be refined down to partial data structures.

²⁴ Today, process is usually understood as a program in progress that has allocated a set of resources and has at least one thread of control. In the 1960s and 1970s were sometimes even simpler definitions common, coinciding with the current term of the control thread (thread).

²⁵ There is no need to create a new control flow in the physical sense: When implementing building blocks as server processes (see [Han70, Hoa78]), the number of physical control flows usually remains constant. The message buffered in the message system logically represents a logical control flow that is simulated by a physical control flow as the message is processed. Such systems are built in the event that more logical than physical control flows can occur, and thus artificially restrict the theoretically possible maximum parallelism. However, if there were enough physical control flows to process all incoming messages from a block immediately, buffering of messages would be superfluous. In practice, the stocking of control flows is associated with high overhead; If, therefore, the supply of control fluxes is replaced by the dynamic generation and destruction of control flows (see historical example [Op165]), one returns to the general asynchronous model, whose degree of parallelism is theoretically not limited.

²⁶ By means of code generation, as with Java, for example, when converting bytecode to targetplate In principle, it is also possible to bind procedure calls to all the mechanisms mentioned at runtime. It would be an interesting research project to do this not only from the source code or from intermediate code representations, but also from already fully compiled code (which might have to contain additional information).

²⁷ Even in the single-user model (Section 3.2), asynchronous control flows can result from notify _ * operations (Chapter 5).

²⁸ If man_code_nolock with (L) RPC combined, you need of course no lock operations insert as it then yes but one are (automatically inserted and during initialization started) control flow; Consistent use of this configuration across all building blocks provides the classic CSP model, which provides significant benefits for debugging and confinement, but otherwise unnecessarily restricts potential parallelism. The combination of code_reentrant with (L) RCP represents a certain amount of waste.

²⁹ Change (internal) identifiers (or original public identifiers to internal identifiers) with a version identifier in order to enable multiple instantiation of the same component type in a combo module. Details are not covered in this work.

Represent ³⁰ whether and in which cases under mandates advantageous descriptions, probably to be examined an interesting question. Structurally, sub mandates are similar to groups of subjects, but submandate creation can be done dynamically at runtime, which in turn could be fragmented into more subordinates. Whether and to what extent such models are predictable and intuitively easy to understand for humans has yet to be investigated.

³¹ After standards are necessary for that purpose at least 64 bits reserved space.

³² The classical concept of the rights tables can be described as a special case of a protected set:
Form the set of all triples (op, subject, object) described by a subject-object mapping table and fill in any further parameter components of the operations with the set of all possible values, which may not be described by the tableau.

³³ In recent times, performance issues have found increased interest in the literature. Despite the efforts to compare different architectures and proposals, this is not always the case; the keyword of the comparison between apples and pears is found not only in [Lie95b].

^However, disrespect can sometimes lead to considerable performance losses. On the other hand, if fast implementation of new functionality is required, the omission of bundles allows so-called "rapid prototyping".

³⁵ yet larger logical address spaces, such as 128-bit or more, well have practical applications: the well-known segmentation model (. See Mullics [Org72] or the memory models of Intel processors) can be achieved by a linear logical address space represented by a (Segment selector, offset) pair, which is interpreted as the logical address of a (holey) linear address space. For example, if the segment selector is 64-bit and the offset is 64-bit, then a 128-bit logical address space will suffice for an equivalent representation of the segmentation model through the linear address space (see also the Microsoft Thunk model for the 16-bit MSDOS transition Memory model to 32 bits).

³⁶ In the old days, the term byte was ambiguous, as it could denote sequences of bits other than the octet. The term is now standardized and denotes exactly 8 bits.

³⁷ For better understanding, one may alternatively introduce the notion of "sequence of operation calls." Then the sequence of operations is a permutation of the sequence of operation calls satisfying the following condition: if the two sequences become one Following this, each original op call comes before its associated operation execution, but this model is to be used only as an aid construct for better understanding.realiter, one does not need to introduce the notion of sequence of ops invocations, but suffice to say of operations The reason for this is not because making this sequence makes certain known difficulties, especially in distributed systems (cf. [AW94]), but because it is not needed to describe the semantics of a purely asynchronous model.

³⁸ In contrast to the consistency model of linearizability is not subject to a special memory semantics here, which must necessarily obey the read and write operations. Below, for example, read operations are treated which expressly permit the delivery of obsolete versions and are therefore not included in the conventional model of linearizability.

³⁷ Im the disjointness of the affected address ranges is sufficient for the commutation of operations executions, but not necessary. So-called "semantic models" try to subsequently interpret or correct the effects of normally non-commutatable operations in such a way that a "correct" result emerges in the sense of any semantic requirements or conditions. Such a correctness concept does not necessarily have to reach the same end state in all possible execution sequences. In contrast to the concept of commutability, I would like to call this quasi-commutability.

⁴⁰ The local refers to a property of the nest, namely its address range, and not to a specific physical distribution on computer nodes or the like.

⁴¹ This term is intended to distinguish the terms determinism and determinism. I do not use the term nondeterminism, because its opposite, determinism, does not occur in an asynchronous model (or occurs only as a special case). Determination is also not given because in general the order of execution of several parallel operations is not fixed. Determinacy is a term used to express an intermediate level between determinism and nondeterminism: while creating a "deterministic" sequence of mutually functionally dependent states, this emergence occurs nondeterministically from operations calls for which order is not preceded.

⁴² The individual elementary operations must of course still better meet the "correctness" or the "validity" on their respective level of abstraction or access granularity.

^In any case, the nests do not give assurances about "correctness", but at most about the (non-) commutability of elementary operations, leaving the callers to decide what semantics they want to implement, while allowing and relying on the assertions of the nest implementation support.

⁴⁴ Newer buffer caches, such as [PDZ99], although unifying caching in a system in a similar way as here, introduce their own interface. In contrast, the principle of universal genericity (Section 2.1.4) requires that the nesting interface is not altered when caching is introduced or discontinued.

⁴⁵ In the historical development of successful operating system kernels such as the UNIX family, so-called "balconies" have been continually added to the existing concepts in order to keep up with changed and extended requirements, while balconies contradict the demand for the lowest possible redundancy of a design Proposed interface concepts and abstractions try to approximate the ideal of universal genericity in order to be able to retrofit future unpredictable requirements with a little luck without balconies.

⁴⁶ If advanced concepts of implementing database systems [HR01] are not sufficiently considered, I hope that these mechanisms can also be integrated into the presented architecture with little effort.

⁴⁷ This also applies to the well-known multiprocessor problem (SMP) and the synchronization problems solved by interrupt locks, which can be solved by suitably implemented elementary operations lock and unlock, provided that interrupts are implemented as fully valid control flows (see [KE95]).

⁴⁸ Conversely, however, also does not guarantee that no alias is created.

^{49 In} general this is simply impossible in distributed systems.

⁵⁰ Interferences do not generally need to be created; for example, external collusion between multiple writers that they only access mutually disjoint areas of a physical data block; A typical application for this is, for example, a message buffer for the mutual publication of any status information that has no influence on the correctness, but is used, for example, for load balancing. The architecture presented here seeks to enable and support, but not enforce, the solution of interference problems through building block implementations, especially those implementers who "know what they are doing" and not for performance overhead through higher level assurances Incidentally, higher-quality assurances can be retrofitted at any time using suitable modules.

⁵¹ Interference is also possible between read-only readers and a writer. The Nest implementation does not take responsibility for this. Section 3.3.5 describes how block implementations through locks can help prevent interference.

⁵² For operating system interfaces between the locking kinds mandatory and advisory distinction is. The locks used here belong to neither of these two types. Although similar to the advisory locking nobody is forced to use locks; however, if a caller instance gets a lock then its compliance is also guaranteed, even if other instances "do not follow the rules." Unlike advisory locking, the lock is bypassed by non-conforming behavior of others Instances prevented.

⁵³ Cf. Semantics of File-Locking in Newer Unix Descendants [Vah96], which includes both the semantics of mutex semaphores and of read / write locks from the database world as a special case

⁵⁴ In the domain of databases this property is called repeatable read.

⁵⁵ If each successful read lock hold multiple instances of the same version, then only one of them convert this success into a write lock, otherwise would have lost the protection against modification by other instances (repeatable read). This does not fundamentally interfere with traditional transactions as the other transactions that try to do so are simply rolled back. Outside of transactions, however, there is the problem that an update to the latest version can not be done through transaction abort, but must be done "by hand" (usually by releasing the now outdated read-lock, re-lock and transfer in read mode Anyone using this mode must therefore reckon with the fact that it does not always work because, in fact, it is a speculation that speculates that no-one other than himself will modify the blocked data certainly also outside of transactions advantageous to increase the potential parallelism, but this is paid for by increased complexity of the program logic.

⁵⁶ Otherwise, it is a (possibly recognizable and sanctionable by error code) errors.

⁵⁷ A so-called "wraparound" of the circular buffer can also be avoided by inserting a move operation as soon as the space at the end of the buffer is no longer sufficient.

⁵⁸ Separate address announcement enables, among other things, a simple solution to a problem that has led to a bloat in the system interfaces, especially in Unix: if a consumer wants to know under Unix, if data is present at an IO channel, he can do so with the help of the system calls select resp poll; generally, however, he can not know the size of the data; The only exception is the socket interface, which allows Lookahead to access data packets under certain circumstances. This historically later upgraded functionality reveals an apparent need for this functionality.

you Unix can not readily inspect data "on suspicion" or several times under Unix (Lookahead), to then decide on the basis of their content you really "consume" them or process them wants to leave it in the buffer by another instance. That one functionality also on regular Files and pipes is needed to see that they are in the standard user library libc is offered in part. If this functionality would not be simulated there first, but already integrated in the core, then some would be through the double Buffering in the core and user address space does not cause conditional anomalies occur. This includes for example, that a lookahead is not between different Processes that want to read from the same pipe work.

⁵⁹ The atomic reserve not does this automatically anyway. It is up to the caller where for him the reserved area used.

⁶⁰ For example, to manage hard disk device driver IO jobs, where rearrangement order is used to increase throughput.

⁶¹ so-called object caches can be realized very simply by using the object size as transfe_size.

With ⁶² get_map (s) is listed at an arbitrary nest s corresponding adjoint nest. The n-fold composition of the get_map function with itself is noted with get_map ⁿ . Then for n> 2: get_map ⁿ (s) = get_map ^{n + 1} (s). The triple adjoint nest thus describes itself.

⁶³ Dating from BSD socket concept and its interface is now implemented in almost all operating systems, even in the operating systems of Microsoft, in all modern Unix variants, and has itself been upgraded in recent versions of IBM mainframe operating systems. Since sockets support and demand packet readings as both an independent subset of subblocks, depending on the mode and circumstances, both with respect to the packet boundaries specified in writing, and the Unix paradigm with resolved packet boundaries, serious operating system designs ultimately do not come around to support both paradigms. If you have to support both paradigms, then this should be done in a consistent way, in as many species of nests as possible, and at all possible levels.

⁶⁴ This mechanism can also be used to file paradigms replicate from other (mostly older) operating systems that do not follow the Unix paradigm from the file as a sequence of bytes.

Get_map ⁿ (s) = get_map ^{n + 1} (s): ⁶⁵ In this case already for n> first

⁶⁶ A variant of move could move the covered area of the target area into the equal-size vacant area of the source area in a single atomic operation, effectively effecting a "rotation operation" without any loss of data, in particular swapping address ranges At the moment I see little practical necessity for this variant, but this variant of move together with clear and delete forms an algebra of operations on address spaces with very nice mathematical properties.

⁶⁷ If you were to introduce ∞ as valid source and destination information for the shift to the semantics could so casually by clear and delete meeting.

⁶⁸ This is very similar to a layered model. For example, a purebred layer model can be modeled by a chain of building block instances. In contrast to layer models, secondary hierarchies and graph-like structures that deviate from a tree structure are also supported. Generally, however, no cyclic wiring is allowed.

⁶⁹ If a newly developed device runs stably in single-user mode, then it can be gradually extended to multiversion competence or behavior.

⁷⁰ This is a conceptually simplistic presentation. Concrete hardware often has an internal hierarchy, such as peripheral buses such as PCI or device buses such as SCSI. In principle, the abstractions nest and building block are also suitable for the realization of their (sub-) drivers, so that the "actual" device driver can also have one or more inputs with which it is connected to the further sub-driver infrastructure I would like to point out that even hardware concepts such as Memory-Mapped-IO, graphics card framebuffer and the like can be easily and efficiently represented by the abstraction of the nests.

⁷¹ In the field of storage area networks (SAN) could be beneficial to introduce multi-user capable driver quite particular ensure higher redundancy and reliability, and possibly the load better distributed. However, the behavior of the remaining components of the participating operating systems must play a role.

⁷² Hardware architectures such as the IBM z-series allow the replacement of memory modules at runtime. This can be modeled by the fact that the primary administrator changes the number of resources changed. If necessary, he must reclaim already assigned resources; see chapter 5.

⁷³ It is important to avoid jamming of the entire system due to the (quasi-persistent) blocks of data which can not be reused in normal operation. A simple solution to this is the requirement that the sum of the maximum lengths of all device_ramdisk instances must not exceed the available main memory. Alternatively, the method of Habermann [Hab69] can be used, which in principle allows overbooking of existing main memory resources (but because of the associated waiting have unacceptable effects on the user-expected behavior of interactive applications or real-time applications can).

⁷⁴ The basic rule was: the more capacity a peripheral provides, the slower it is:
At the time of writing this paper, cheap mass-produced hard drives broke through the 100-gigabyte limit, the same size as tape drives (perhaps with the exception of a few very expensive high-end models). The media costs per GB are also slowly approaching the same magnitude. I expect that similar shifts in the current memory hierarchies will continue in the future.

⁷⁵ The use of multiuser inputs is possible, but depending on the selected internal structure may be costly. Even with client-server applications, it makes sense to first transform a static nest into a dynamic one using map_ *, before it is exported, for example, remotely.

⁷⁶ This expectation is ultimately justified on closer examination only by the fact that the current external memory technology, especially that of hard disks, poor locality properties due to the moving parts has (see also the discussion in the literature so-called "memory space") In the foreseeable future, high-capacity external memories will be available with not only much higher data transfer rates and lower latency, but also better locality characteristics at competitive prices, such as holographic memories or high-capacitive semiconductor memories based on magnetic or quantum effects have only limited relevance to the fragmentation problem.

⁷⁷ This includes, for example, shifts by constant offsets, which are necessary in any case, if, for example, space is reserved for the translation table at the beginning of the entrance nest. I do not want to give a clean mathematical definition of such mappings, but a characterization of properties that are relevant to the architectural design.

⁷⁸ Regardless thereof should map_simple_delta only when such a load characteristics are applied, where only relatively rare shift operations are required (which can be quite expected in many applications), or where conversely extremely frequent shifts, but only relatively few address Access, so that the address translation effort at the amortized cost is of little importance.

⁷⁹ Another solution, Crash Consistency Checking, is impractical because of its poor repair characteristics and complexity, as a standard means of remedying the effects of crashes, but in an emergency it looks different). The complexity of a consistency test can be very large because of the possible fragmentation of a nest in many small patches in the manner of a Swiss cheese.

⁸⁰ Conceptually, this restriction corresponds to a chemical also in conventional file systems compulsory that the sum of the space required may not exceed the total size of the file system of all stored files. If there are very large sparsely populated nests in a dir_ * hierarchy whose utilization falls below a heuristically determined threshold (which, in the case of frequent occurrences, can lead to the problem that an address space with 64-bit width is no longer sufficient for the sum of all occurring address space sizes ), then a reduction of the virtual address space sizes can be achieved by an intermediate map _ * block.

⁸¹ In fact, he also has an output, namely the virtual user address space. For hardware reasons, however, this no longer has the same interface with the basic operations presented here. In the abstract sense, a processor-MMU team still performs the same basic operations: main memory accesses of the processor can be modeled as combinations of get and put with transfer operations; an MMU abstractly operates a limited type of virtualization, such as a dy Namish nest provides.

^82, if the logical address space of a cavity is larger than the virtual address space of a process is implemented (for example, 32-bit hardware), then only a portion of logical address space nest for direct access by machine instructions.

⁸³ usually requires MMU hardware an auxiliary storage for the page tables. This is not executed here as a separate input, because a different wiring than with device_mem for hardware reasons is usually not possible.

Use ⁸⁴ Despite the need for auxiliary storage for the page tables working, a mmu _ * - Instance logically stateless: you can always share the entire page table, without a loss (except possibly performance degradation) occurs because the page fault then inevitably encountered the Status of the table again from the entrance nest to reconstruct as necessary.

⁸⁵ Only this place has the full overview of the current storage situation and can reasonably estimate reliably how high future memory request rates could fail or whether the situation is critical. The recoveries on suspicion can be adapted to the current load conditions, so that unnecessary overhead is minimized.

⁸⁶ Compared to conventional strategies, which often start with the outsourcing only when already inserted memory shortage, leading to potentially increased IO traffic. However, since this is done with background priority, it bothers ongoing activities as good as not.

⁸⁷ A conventional paging on background storage is not an independent concept in the architecture presented here. Private segments are always executed as temporary nests that are kept on mass storage. In the case of stack segments, they are (almost) empty at the beginning; with increasing size new space is requested by means of clear; the outsourcing of their content can be done speculatively by Background-IO.

^{In the} mid-1990s, there was a great deal of discussion about kernel sizes and boundaries between core and "user space" in the operating system domain, avoiding the notion of an operating system kernel, as it is often associated with monolithic structures There can be several cores in the conventional sense: for example, the connection to the MMU hardware can take place separately from the control flow administration, if necessary also take place in different protection areas If only one copy of a given hardware mechanism exists in a system (For example, a common interrupt jump table in a multiprocessor system), then there will naturally be only a single management instance for the associated management software, but with hardware units that are independent of one another, there may well be several different management instances that you in ko could call conventional non-self-contained micro-nuclei. Such modularization brings advantages in particular when adapting to changed or extended hardware components. This problem occurs in particular due to the advancing technical development of device drivers and is insufficiently solved in many minimalization approaches of cores such as the Exokerel architecture [EKO95].

⁸⁹ This shows a certain similarity to the opportunistic locks used by Microsoft in particular [OpL]. However, opportunistic locks do not necessarily have to be granted, and they are broken if necessary, ie they are withdrawn with brutal force. Although the model propagated in section 5.3 does allow for this in extreme cases, it usually pursues the idea that a consensus should be reached on the distribution of locks. Opportunistic locks, on the other hand, represent an independent concept that exists alongside or in addition to the "normal" lock as an alternative to performance enhancement, and in this respect, the approach presented here differs fundamentally from Microsoft's.

⁹⁰ One approach to avoiding deadlocks in databases is conservative locking (see eg [GR93, VGH93]), where all resources used by a transaction must be requested atomically once at the beginning (see also the "Craftsman Problem" in [Jür73 ], which is a generalization of the well-known philosopher problem [Lam74]), but this either requires accurate a-priori knowledge of future behavior, or it restricts parallelism to a great extent by unnecessary speculation on later mostly unused resources With previously unknown behavior of the transactions, incremental real-time 2-phase locks result in a dead Lock problem that can not be avoided a priori (the posteriori detection, however, is relatively simple, but so that unpredictable rollbacks are accepted). Although deadlocks can be avoided by semi-ordinarily (cycle-free) setting of locks, one must also know the future behavior of the transactions a priori, which is seldom the case in practice. If you absolutely have to avoid rollbacks as in some operating system applications, and / or if you do not know the future behavior of consumers, then in general only helps to limit the scheduling by requesting eventually not really needed locks, ie the possible degree of parallelism reduce. Therefore, it is of immense importance to use such locks that disturb each other as little as possible. The multiversion model (Chapter 7) can also contribute to this.

⁹¹ deadlocks can not only transactions, but also in multi-user or multi occur version behavior of applications that can bypass the parallel with the presence of activities (eg code_reentrant in Section 2.6). I do not see deadlocks inherent in the transaction paradigm, but parallel processing on common data. In contrast to the classical transaction paradigm, which tries to hide the effects and consequences of parallel processing from the consumers, the singleuser and multiuser model makes this problem explicit. While this places greater demands on the programmers, it allows for finer-controlled responses to deadlocks, such as requiring a process to receive a signal or being asked or forced to return a single lock, without having to roll the manslaver of a rollback ,

⁹² I do not think that transactions are very useful because they allow for a single-user illusion, but because they can increase the degree of parallelism in terms of an optimistic strategy and offer the rollback functionality explicitly; This is also very useful for multiuser transactions.

⁹³ exceptions with "crooked" sector sizes occur, such as older disk devices and some modern compatibles special hard drives from IBM that are intended for storing ISAM information. Further, in the CD-ROM standard, some crooked sector formats, to the current operating systems only the raw unbuffered access is supported.

⁹⁴ The concept of the nests expressly supports completely any transfer sizes. However, if you use primes as a transfer size, it is your own fault and can not expect a particularly good performance in the episode.

⁹⁵ As it probably still relatively frequently happens that on the case, only one consumer just keeps data blocks, or that a recovery by the later discussed notify _ * - operations is possible shifts are likely to be worthwhile in many cases. But to do this, the operations on nests have to be extended in some way by a physical-level displacement mechanism, which I will not describe in detail here. One way to do this would be to use try_move, a shift operation that prompts the consumer to perform a move, provided that it has no side effects on other users. Alternatively, the get operation could be extended by parameters that express an allocation request to which the producer but does not necessarily have to comply.

This argument ⁹⁶ runs parallel to that of the theory of compression method, which states that a lossless data compression of n output bits always contain encodings must longer than n, if some codes are shorter than n fail. This is because there are a total of 2 ⁿ different input encodings to be translated into 2 ⁿ different output encodings since the compression should be reversible in all cases.

⁹⁷ Of which, in my opinion, the most important is the avoidance of waste.

⁹⁸ To simulate an n-fold hardlink, this block must be instantiated n-fold, and there must also be added a management logic for the release, which can be done, for example, by a separate management module, which, so to speak, the "supervision" of all name changes and shifts of all involved Alternatively, this block can also be executed in such a way that it receives n control inputs, which together take over this task.

⁹⁹ There are attractive applications for this, as long as there are methods for reintegrating splits. Examples of splits occur, for example, in software source code version management systems.

¹⁰⁰ For special applications, such as extremely high reliability, this idea might be interesting, despite its high cost.

¹⁰¹ What impact this can have on performance is another question. In principle, we have implemented a NUMA architecture in software.

¹⁰² After initial start blocks (indispensable device drivers and equivalent of a root file system) must already be present for the system to go into operation.

¹⁰³ This separation causes, among other things, that the abstractions nest and building block can be used in a uniform manner in conventional "user processes", possibly even in so-called "application programs" - there is absolutely no fundamental difference between "core" and "user" Address spaces or protection areas.

¹⁰⁴ In extreme cases, the entire operating system can run in a single address space, which, for example, provides performance advantages in the case of real-time controllers. If protected areas are used, a usable access protection can still be realized (see [C ⁺ 94]). In contrast to known architectures (see [K ⁺ 97]), the separation option presented here allows arbitrary intermediate stages between pure single-address-space models and complete fragmentation of all functions into separate mmu_ * instances.

^105. The use of a single virtual address space in the entire system can be characterized model that only a single mmu _ * - instance exists, in which the entire system running. Although this strategy has received much attention in the literature lately [C ⁺ 94, Ros94, Ass96], I see no fundamental advantage in it. Switching a standard MMU to different protection zones costs (with a few exceptions) in the worst case the same order of magnitude as switching between different address spaces; only the best case may be more efficient. The extent to which this possible performance gain affects the overall system, and whether effects of the same magnitude can not be achieved by other architectural measures, are questions to be examined more closely. In my opinion, the restriction to a fixed single-space model is a limitation that can be broken with the architecture presented here.

¹⁰⁶ The simplest solution for this is that the tmp input has been in the "Ur-instantiation" the right process image with the block configuration, is to start with. If this control instance includes the controlling automatically creates the Self-administration: When system generation of a bootable system, a corresponding process image is created on a (foreign) computer with all instances required for the initial start, which can then be loaded with conventional loaders in the same way as classic Unix cores.

¹⁰⁷ This may iA be problems with recursion if such clients give yourself operations in question in order.

¹⁰⁸ As an alternative to these inputs and outputs, you could also use remote LRPC variants; so no wiring lines between communication channels would have to be managed on the same computer. However, the explicit management of lines by a higher-level entity seems to me to be more secure, since a line already provides a rudimentary form of authentication which, with suitable partitioning of the subsystems (eg partitioning into protection areas), is burglar proofed by a trusted "logical supervisor" can, without having to resort to less extensive measures such as encryption in the LRPC.

¹⁰⁹ This is not vorschaltet only for the production of multiple virtual machine partitions interesting or to their communication on common information, such as "file systems", but also for example for Checkpoint / Restart a single operating system instance, if you tmp for example, before a transaction instance. A Another application would be, for example, the provision of a complete replacement operating system image, which can intervene in case of interference.

¹¹⁰ To smooth re-Instantierungen or guarantee reconstructions, the contents of code at runtime just to new device types or new (bug-free) versions can be extended, but not modified.

¹¹¹ In safety-critical applications running Instantüerungs- and constructor routines may present a risk, especially when the in the downstream mmu _ * by the control instance - instance running activities or the content of code can not be trusted. In this case, the call should be made by LRPC and executed in the context of the downstream mmu_ *.

¹¹² through intermediate remote devices should provide new databases Konfiguationsmöglichkeiten Also in the classical application areas that were not easy to implement in existing database architectures. Particularly noteworthy here is the inclusion of the behavior of bottlenecks as remote entities in cross-computer query optimization strategies; For example, in some scenarios, it may be beneficial to export tables to client machines remotely and cache them there before committing large joins or other products.

¹¹³ Through such compounds could be, for example, pathname by replacing SQL queries.

¹¹⁴ This approach goes far beyond integrating files into databases (see [HR01, Section 3.5]), as both files and database records can be accessed through both SQL and directory paths; At this level of integration, the conventional differences between databases and operating systems are blurring completely.

¹¹⁵ The only exception is the death of an owner.

¹¹⁶ For example, purchase property, on which the king does not have access in an absolute monarchy a subject. If this were not possible, the subjects would starve to death because without the King's consent they would not be able to acquire property or possession of food, including food they themselves produced.

¹¹⁷ At the start of the operating system of all the memory owned by a Urbesitzer, which then "borrow" it to other instances such as caches or device_ramdisk.

¹¹⁸ When producing copies, then ultimately operates a hybrid of the assignment of ownership of different instances. The "originals" are managed at the bottom of the hierarchy (see MMU-free original Unix with buffer cache in [Lio96]), the copies then arise implicitly, eg during read or write operations.

¹¹⁹ How much sense does it, is another question. Theoretically, an MMU-free process can run faster, eliminating the hardware overhead of address translation, and guaranteeing no delays due to page fault interruptions. The latter effect is achieved in real-time operating systems but also by preloaded and non-pageable memory pages.

¹²⁰ If the recipient eg goes into an infinite loop or, for example in the execution of the notify _ * - operation in a deadlock device or if, for example in the RPC model, the processor control flow passes away, a "refusal" may also simply be that nothing happens. Since internal matters of a building block should not be "mixed up" from the outside, the only solution to this problem is to set a time limit whose sequence is interpreted as a "refusal".

¹²¹ Unless otherwise prevented by other authorities, such as security guards. However, this is not a counter-argument, as a guardian instance should also consistently monitor the recovery, so that the bottom line is a division of power to multiple instances (mutual monitoring).

¹²² Microsoft's opportunistic locks are their own locking-type, independent of other locking types. This not only increases the complexity of the interfaces, but may, for example, lead to the situation that a malicious application, which has been deprived of an opportunistic lock, can still shut down the system by means of regular locks.

¹²³ I do not consider the common problem of reliability to be specific to distributed systems, although a viable solution is of particular importance there. Failover security concepts should be uniform across all building blocks, regardless of physical distribution.

¹²⁴ Advances in communication technologies, however, go in the direction that the best-case assumptions are always better approximated by improved technology.

¹²⁵ This does not mean the granularity of individual write machine operations, but rather a "timely" message in the order of the communication latencies.

¹²⁶ If the assumption of disjoint working sets is not correct, the "guilt" is not the caches, but the behavior of the end consumer.

¹²⁷ Messages are used to transmit information (conversely, non-transmission or non-arrival of a message may also constitute information, eg when a timeout expires, see [Lam84]). Transmission of information need not necessarily be done by making a copy; For example, the use of a shared buffer by multiple instances represents a realization of a message transmission.

¹²⁸ This could be avoided by using get_ops (get_ops (s)), ie inserting an Operations nest into the Operations nest.

¹²⁹ In the latter case, an asynchronous call is possible. How much sense this makes is obvious, since the elementary operations were developed especially for the representation of asynchrony.

¹³⁰ The necessary considered marshaling the RPC often (conversion between incompatible data formats) is not inserted here into the basic mechanisms, but can be implemented by adapting modules as needed, convert the various data formats into each other.

^A closer look at current monolithic core implementations in the Unix environment reveals that they make excessive use of dynamic type checks. This is evidenced, for example, by the existence of the error response EINVAL (Invalid Argument) in Unix. There are hardly any system calls that require parameters where instead of processing a call job, this error code can not come back as feedback.

¹³² This type inference systems are not generally excluded: the Section 4.2.2 presented strategy _ * - modules can not only carry out run-time test for type compatibility, but trigger in principle any subsequent instantiations with any parameters. This should theoretically make it possible to realize even a Hindley-Milner type system.

¹³³ These are used for example in Unix to differentiate the operations to be performed with ioctl and fcntl. Enough has already been discussed in folklore literature about the problems and implications. At the speed of today's processors, the minimal overhead involved in accessing strings over access to a machine word can no longer be a beating argument, especially if you sacrifice comfort.

^{In theory,} one could even omit the list of operation names. Although the processor can then check the data format of all incoming jobs themselves, the caller in this case is completely "blind" and can only guess the operation name if he does not use it from another external source (such as an interface definition). If no type information is communicated at all, then it is not a type system in the true sense.

¹³⁵ This issue surfaced in operating systems again and again, not only in those that specify object orientation as a leitmotif. For example, Microsoft coined the term "DLL hell" to mean incompatible versions of system libraries that do not match because of internally changed interfaces.

¹³⁶ examples of the concrete syntax of system-wide interfaces, among other things found in the Internet RFCs (Request For Comments). Data formats are almost always indicated by context-free grammars in a notation similar to the Backus-Naur form.

¹³⁷ Evidence of this are the formal specification of network protocols and -Datenformaten in Internet RFCs. These all seem to me to be in the class LL (k).

¹³⁸ In the Greibach Normal Form all production rules have the form X → have aα, wherein X, a is a terminal symbol, and α an arbitrary string of terminal or non-terminal symbols is a non-terminal symbol.

¹³⁹ Typical members of sequences are arrays and records.

¹⁴⁰ In general, context-free grammars alternative rules can represent multiple logical alternatives represent logical alternatives on various issues and nothing to do with each other in a logical sense have need.

^For example, this concept appears in the tags of variant records of Pascal-like programming languages; In Ada, the use of a tag field is even mandatory.

¹⁴² This does not preclude the use of a pre-compiler, which calculates recurring parts of the interpretation once in advance (so-called pre-computing).

¹⁴³ Whether the pre-translation into executable machine instructions ( "just-in-time compiler") can bring additional benefits would be to investigate.

¹⁴⁴ This concept appears in compilers as a token class, eg the token class of all identifiers or all character strings.

¹⁴⁵ A reduction can be achieved in that the attributes and methods will no longer appear in the meta nests so that they appear from the hidden type system. Improved access protection can be realized by the fact that in the transformation also fades in the respective adjoint nests are made.

¹⁴⁶ An exception is Smalltalk, where methods changes or even classes changes at runtime are possible in principle, since all structures are created dynamically.

¹⁴⁷ examples are Pipe operations in Linux, whose semantics is dependent on the mode in which the pipe was opened. There are implementations that implement each mode as a separate procedure and make it available through a single generic interface.

¹⁴⁸ Usual safety concepts of object-oriented programming languages such as C ++ or Java provide a globally valid division into private and public areas. In contrast, the concept of adjoint nests also allows views that may be different for each participant instance.

¹⁴⁹ In object-oriented inheritance, method interfaces are always only extended. On the other hand, blocks also allow the masking of previous attributes or methods. I think this is very useful because it makes it possible to increase the level of abstraction in a building block hierarchy: logically speaking, after increasing the level of abstraction, it is still the same object instance, but the accessors become more abstract prohibit the higher levels of abstraction from using them mixed with lower-level methods, for example, to prevent the circumvention of assurances given above ("black interfaces").

¹⁵⁰ A classic example of universal higher-level interpreter constructs is the #! Operator, along with the argument passed to processes in Unix, which can be used to start arbitrary interpreters, which in turn can perform arbitrary operations on arbitrary data. A simulation by building blocks is easily possible.

¹⁵¹ Several tables, indexes, etc. should be cut out by reservation sufficiently large address ranges from a minimum of 64 bit address space overall size so that displacement of entire tables are not at all or only extremely rarely needed.

¹⁵² Possibly it would introduce a good idea adjoint nests for adjoint nest. The adjoint-adjoint nest then contains the description of whole tables and indices, the simple adjoint nest the concrete description of the respective table.

¹⁵³ Well-known implementations are, for example, the logs of databases that sometimes pop up completely be preserved and displayed as an SQL table so that you can search in them as in other tables.

¹⁵⁴ Conceptually, this would be the use Lamportscher watches [Lam78] time as a permanent model of representation in persistent storage relationships between operations.

¹⁵⁵ When Time Warp [Jef85] is likewise a virtual time axis used, but the operation Auführungen proceed on this axis monotonously forward and be reset only occasionally Internal rollback. In contrast, the model propagated here allows any backdating of operations that are independent of any rollbacks that may occur; furthermore, the virtual time axis is linked to the location axis to a two-dimensional plane.

¹⁵⁶ It is also logical Lamportschen watches, only has the consumer then the "meaning" of time values in real-time to determine hard way yourself.

¹⁵⁷ In this illustration is still-silent set beforehand that always unambiguous timestamps are generated in a distributed system. A well-known method for this is the attachment of node flags to the read value of a computer clock, so that possibly identical clock times, which could result from random "simultaneous" reading of clocks, always leads to unique time values.

¹⁵⁸ With quasi-persistence means that basically the persistence is indeed angesprebt, the stored information can be coarsened by selectively forget but later.

¹⁵⁹ The concept of a "global order" of operation statements need not be used in a distributed system, the representation by order numbers is for illustration purposes only.

¹⁶⁰ More general models are conceivable in which it is not the views between locks that are important, but the access operations they contain. As long as in the example only Lock 2 was set but not read, Lock 3 could still be granted. The resulting more complex model is not investigated in this paper.

¹⁶¹ This is similar to to indeterminate state dependencies in Section 3.2, however, does not apply to the states themselves, but to the data stored in the states causal dependencies.

¹⁶² The determination of all possibly affected Lock instances does not have to be done every time you attempt to set them, if the principle of dynamic programming is used. Furthermore, an implementation may reject the later interposing of locks, even if this were possible according to stable statements. As a result, heuristics can be introduced which, for example, block relatively large areas of the space-time level against the setting of new write locks.

¹⁶³ More consistency models, in particular causal semi-ordered (eg [BSS91]), can be, if appropriate, direct-parameters by replacement of the type boolean specifying by an enumerated type, the intermediate stages between disorderliness and total order to express causal dependencies.

¹⁶⁴ If this indivual adjustment is not needed, you can move from lock and thus simplify the interface them into the parameters. Which semantics should result from individual settings and whether this is valid or rejected in the sense of a certain semantic model can also be determined (partially) in the concrete building block implementation of the engineer instance. Otherwise, the caller has the choice of a tremendous variety of semantics, which he can specify by his parameter choice. As a very simple example, an empty set of queues can be used to specify that there are no functional dependencies; This can occur during the initialization or deletion / unconditional overwriting of the data content and, together with the backdating option on the virtual time axis, increase the parallelism of this possibly long-lasting process with other activities.

¹⁶⁵ In contrast to [CL85], a snapshot can retroactively make in the virtual timeline.

So far, ¹⁶⁶ versioning was in databases seem only for decoupling between readers and Used recorders. In contrast, the model presented here, in principle, also allows the decoupling between parallel active recorders; Restrictions arise only from the causal dependencies.

¹⁶⁷ The classic bottleneck problems of distributed systems, particularly that caused by latency, can also be from the point of resisting sprechener optimization objectives (trade-offs) look. It would be interesting to unify the presentation of this area with the trade-offs raised here.

¹⁶⁸ A catchy phrase to characterize both extremes could read as follows Locks as a container on the virtual Zeitache on the background of consideration: In transactional semantics containers are kept as long as possible open (to them if necessary to declare invalid), the mutual Exclusion, containers are closed as early as possible.

Claims (4)

Method of regulating data access a system consisting of several individual systems on data at least a data storage device in which the individual systems are free Reserve data or address ranges of the data source and the reserved areas for an access by other individual systems are then locked, wherein the reservations (locks) a local and have a temporal component. Method for regulating data access to data at least one data storage device in which address ranges and / or partial address areas of the data storage device thereby be moved that while preserving the physical addresses the assignment of logical addresses to the physical addresses according to the shift operation changed becomes. Method for regulating data access in a system consisting of several individual systems on at least one Data storage device in which the individual systems are free data or reserve address areas of the data storage device and the reserved areas for an access by other individual systems are then locked, wherein across from the directly needed Areas speculatively enlarged areas reserved. Method according to claim 3, characterized that each over the directly needed Area reserved reserved expansion area at a corresponding reservation request from another individual system or a data storage device at least partially released becomes.