My knowledge of Talmud is, to be generous, zilch, but consider the format and style of Talmud. This is what you get when each commentator takes the arguments of colleagues and predecessors seriously. In the center a discussion between one group of experts, commented on and amplified by a second group. On the side a detailed line-by-line commentary and then on the other side a series of comments and explanations. This is the direct opposite of what we find in the computer science literature – where a mass of following footnotes is generally there as a required nod of the head or to provide the illusion of scholarship, but there is very little effort to actually wrestle with the existing body of knowledge. As Spolsky shows (this must be my month to comment on Spolsky) applying such detailed analysis to trivia just elucidates the trivial nature of the material. But imagine if we did this for serious scientific work.

Comments

This is really the first “structuring” paper for OS design.

The non-real-time aspect of this is critical- note that for a real-time system the synchronization may not be necessary.

The “shell” is split off from the OS and turned into a user program only in the 1960s in CTSS

Dijkstra writes before such problems as cache locality existed

Dijkstra: THE Processing System 1968.

Therefore we have arranged the whole system as a society of sequential processes, progressing with undefined speed ratios. To each user program accepted by the system corresponds a sequential process, to each input peripheral corresponds a sequential process (buffering input streams in synchronism with the execution of the input commands), to each output peripheral corresponds a sequential process (unbuffering output streams in synchronism with the execution of the output commands); furthermore, we have the “segment controller” associated with the drum and the “message interpreter” associated with the console keyboard. This enabled us to design the whole system in terms of these abstract “sequential processes.” Their harmonious cooperation is regulated by means of explicit mutual synchronization statements. On the one hand, this explicit mutual synchronization is necessary, as we do not make any assumption about speed ratios; on the other hand, this mutual synchronization is possible because “delaying the progress of a process temporarily” can never be harmful to the interior logic of the process delayed. The fundamental consequence of this approach–viz, the explicit mutual synchronization–is that the harmonious cooperation of a set of such sequential processes can be established by discrete reasoning; as a further consequence the whole harmonious society of cooperating sequential processes is independent of the actual number of processors available to carry out these processes, provided the processors available can switch from process to process.

Explication

A process combines program code and state (usually a stack and some memory for process global variables). User programs are applications, the other processes constitute the (operating) system – drivers for input and output devices and segment controller (disk buffer manager) and “message interpreter” (shell).

Mutual synchronization statements are semaphores – this paper introduces their use.

The fundamental property of a time shared system is that the system can schedule at will because “delaying a process temporarily… ” But this also requires that the system is “live” or else we don’t have the “temporarily” property.

Partitioning into processes that are explicitly synchronized simplifies the operation of the system because each process can be independently verified.The design extends to multiple processors
Talmudic codes

2 thoughts on “Talmudic codes”

Comments are closed.