英訳 P164〜P165 8.3.3
8.3.2 The “Habermann” Hierarchy in the
T.H.E. System
8.3.2 T.H.Eシステムでの「ハーバーマン」階層
The T.H.E. system was also hierarchical in another sense. In order to make the system relatively insensitive to the number of processors and their relative speeds, the system was designed as a set of “parallel sequential processes”.
T.H.Eシステムもまた他の感覚において階層的でした。システムを、プロセッサーの数およびそれらの相対速度に比較的鈍感にするために、システムは、1セットの「並列の一連なプロセス」として設計されました。
The activities in the system were organized into "processes" such that the sequence of events within a process was relatively easy to predict, but the sequencing of events in different processes were considered unpredictable (the relative speeds of the process were considered unknown).
システムでの活動は「プロセス」へ組織されました、そのようなプロセス内の出来事のシーケンスを予言することが比較的容易だった、しかし異なるプロセスでの出来事の順序は予測不能である(プロセスの相対的な速度は、未知である)と考えられました。
Resource allocation was done in terms of the processes and the processes exchanged work assignments and information.
資源配分はプロセスによって行われました。そしてプロセスは仕事割り当ておよび情報を交換しました。
In carrying out a task, a exchanged work assignments and information.
タスクを行なう際に、交換された仕事の割り当てと情報。
One important relation between the processes in such a system is the relation "give work to".
そのようなシステムのプロセス間での重要な1つの関係は「〜に仕事を与える」関係です。
In his thesis [6] Habermann assumed that "gives work to" defined a hierarchy to prove "harmonious cooperation".
彼の命題[6]では、ハーバーマンが「〜に仕事を与える」は「調和した協力」を証明するための階層を定義したと仮定しました。
If we have an Operating System we want to show that a request of the system will generate only a finite (and reasonably small) number of requests to individual processes before the original request is satisfied.
もしオペレーティング・システムを持っていれば、私たちは、オリジナルの要求が満たされる前にシステムの要求が個人プロセスへの要求の有限の(かつ合理的に小さな)数だけを生成するだろうということを示したい。
If the relation "gives work to" defines a hierarchy, we can prove our result by examining each process separately to make sure that every request to it results in only a finite number of requests to other processes.
もし「〜に仕事を与える」関係が階層を定義するなら、私たちは、他のプロセスへの要求の有限数だけにそれへのすべての要求が帰着することを確かめるために各プロセスを別々に検討することによって、結果を証明することができます。
If the relation is not hierarchical, a more difficult, "global" analysis would be required.
もし関係が階層的ではない場合、より困難で、「全体的な」分析が要求されるでしょう。
Restricting "gives work to" so that it defines a hierarchy helps in the establishment of the "well-behavedness", but it is certainly not a necessary condition for "harmonious cooperation".
「〜に仕事を与える」を制限するその結果、それは「well-behavedness」の設立を支援する階層を定義します。しかし、それは必ず「調和した協力」のための必要事態ではありません。
In T.H.E. system the two hierarchies described above coincided.
T.H.E.システムでは、上記であると記述された2つの階層が一致しました。
Every level of abstraction was achieved by the introduction of parallel processes and these processes only gave work to those written to implement lower levels in the program hierarchy.
抽象の毎レベルは並列のプロセスの導入によって達成されました。そしてこれらのプロセスはプログラム階層中のより低いレベルを実行すると書かれたものにこれらの仕事を与えました。
One should not draw general conclusions about system structure on the basis of this coincidence.
人は、この一致に基づくシステム構造に関する一般的な結論を引き出してはなりません。
For example, the remark that "building a system with more levels than were found in the T.H.E. system is undesirable, because it introduces more queues" is often heard because of this coincidence.
例えば、「それがより多くの待ち行列を導入するので、T.H.E.システムで見つかったより多くのレベルを備えたシステムの構築は、不適当である」という発言は、この合致のためにしばしば聞かれます。
The later work by Dijkstra on structured programming [21] shows that the levels of abstraction are useful when there is only process.
構造化プログラミング[21]の上のダイクストラによる後の仕事は、プロセスだけがある場合、抽象のレベルが有用なことを示します。
Further, the "Habermann hierarchy" is useful, when the processes are controlled by badly structured programs.
さらに、プロセスが悪く構造化したプログラムによってコントロールされる場合、「ハーバーマン階層」は有用です。
Adding levels in the program hierarchy need not introduce new processes or queues.
プログラム階層中のレベルを加えることは新しいプロセスあるいは待ち行列を導入する必要がありません。
Adding processes can be done without writing new programs.
プロセスを加えることは新しいプログラムを書かずに行うことができる。
The "program hierarchy" is only significant at times when humans are working with the program (e.g, when the program is being constructed or changed).
人間がプログラムを用いて仕事をしている場合(プログラムが構築されているか変更されている場合、e.g)、「プログラム階層」は単に時々有効です。
If the programs were all implemented as macros, there would be no trace of this hierarchy in the running system.
もしプログラムがすべてマクロとして実行されれば、ランニングシステムにこの階層の跡はありません。
The "Habermann hierarchy" is a restriction on the run time behavior of the system.
「ハーバーマン階層」はシステムの起動時間の動作に対する制限です。
The theorems proven by Harbermann would hold even if a process that is controlled by a program written at a low level in the program originally written at a higher level in the program hierarchy
ハーバーマンによって証明された定理は、プログラム階層でもともとより高いレベルで書かれたプログラムの中で、低いレベルで書かれたプログラムによってコントロールされるプロセスだとしても有効だろう。
There are also no detrimental effects on the program hierarchy provided that the programs written at the lower level are not written in terms of programs at the higher level. Readers are referred to "Flatland" [7].
もしより低いレベルに書かれたプログラムがより高いレベルのプログラムに関して書かれていなければ、プログラム階層上にもまた弊害をもたらしません。読者は「フラット」[7]を参照されます。
8.3.3
Hierarchical Structures Relating to
Resource Ownership and Allocation.
8.3.3資源所有権および割付けに関係のある階層的構造。
The RC4000 system [8] and [9] enforced a hierarchical relation based upon the ownership of memory.
RC4000システム[8]および[9]は、メモリの所有権に基づいた階層的関係を強化しました。
A generalization of that hierarchical structure has been proposed by Varney [10] and similar hierarchical relationships are to be found in various commercial operating systems, though they are not often formally described.
その階層的構造の一般化はVarney[10]によって提案されました。また、それらはあまり形式的に記述されませんが、同様の階層的関係は様々な商用オペレーティング・システムで見つかることです。
In the RC4000 system the objects were processes and the relation was "allocated a memory region to".
RC4000システムでは、対象がプロセスでした。また、関係は「メモリ領域を割り付けられた。」
Varney proposes extending the relation so that the hierarchical structure controlled the allocation of other resources as well.
階層的構造が同様に他の資源の割付けをコントロールしたので、Varneyは関係を拡張するつもりです。
(In the RC4000 systems specific areas of memory were allocated, but that was primarily a result of the lack of virtual memory hardware; in most systems of interest now, we can allocate quantities of a resource without allocating the specific physical resources until they are actually used.)
RC4000システムの中で、メモリの特定のエリアが割り付けられた。しかし、それは第1に仮想記憶ハードウェアの不足の結果でした;今のほとんどの興味のあるシステムでは、私たちが、それらが実際に使用されるまで特定の物理的な資源を割り付けずに、多量の資源を割り付けることができます。
In many commercial systems we also find that resources are not allocated directly to the processes which use them. They are allocated to administrative units, who, in turn, may allocate them to other processes. In these systems we do not find any loops in the graph of "allocates resources to", and the relation defines a hierarchy, which is closely related to the RC4000 structure.
多くの商用システムでは、私たちが、さらに資源がそれらを使用するプロセスに直接分配されないことを知ります。それらは、次には他のプロセスにそれらを分配してもよい管理上のユニットに分配されます。これらのシステムでは、私たちは「〜に資源を割り付ける」のグラフにほとんどループを見つからない。また、その関係はRC4000構造と密接に関係する階層を定義します。
This relation was not a significant one in the T.H.E system, where allocating was done by a central allocator called a BANKER.
Again this sense of hierarchy is not strongly related to the others, and if it is present with one or more of the others, they need not coincide.
この関係は、割り付けがBANKERと呼ばれる中央の割付けルーチンによって行われたT.H.Eシステムの中で重要でないものの一つでした。再び、階層のこの感覚は、強く他のものと関係がありません。そして、もしそれが他のものの1つ以上で存在する場合、それらは一致する必要がありません。
The disadvantages of a nontrivial hierarchy (the hierarchy is present in a trivial form even in the T.H.E system) of this sort are (1) poor resource utilization that may occur when some processes in the system are short of resources while other processes, under a different allocator in the hierarchy, have an excess; (2) high overhead that occurs when resources are tight.
この種の不自明な階層(階層は、T.H.Eシステムでさえ重要でない形式の中にあります)の損失は、(1)システムでのいくつかのプロセスが、他のプロセスが階層の中の異なる割付けルーチンの下で超過を持つ間の資源に短い時に、生じるかもしれない貧弱な資源利用です;(2)資源がきつい場合に生じる高いオーバーヘッド。
Requests for more resources must always go up all the levels of the hierarchy before being denied or granted.
The central "banker" does not have these disadvantages.
A central resource allocator, however, becomes complicated in situation where groups of related processes wish to dynamically share resources without influence by other such groups.
より多くの資源の要請は、否定されるか与えられる前に階層のすべてのレベルを常に上るに違いありません。中央の「銀行家」はこれらの損失を持っていません。しかしながら、中央の資源割付けルーチンは、関連するプロセスのグループが他のそのようなグループによる影響のない資源をダイナミックに共有したい状況で複雑になります。
Such situations can arise in systems that are used in real time by independent groups of users. The T.H.E. system did not have such problems and as a result, centralized resource allocation was quite natural.
そのような状況は、ユーザの独立したグループによってリアル・タイムにおいて使用されるシステムで発生することができます。T.H.E.システムはそのような問題を持っていませんでした。また、その結果、中心に集められた資源配分は全く自然でした。
It is this particular hierarchical relation which the Hydra group rejected.
They did not mean to reject the general notion of hierarchical structure as suggested in the original report [1] and [11].
それはイドラ・グループが拒絶した特にこの階層的関係です。それらは、オリジナルの報告書[1]および[11]の中で主張されていることとして階層的構造についての一般的な概念を拒絶することを意味しませんでした。