RC 4000

Rating - 3/5

RC 4000

 The RC 4000 system, like the THE system, was notable primarily for its design concepts. It was designed for the Danish 4000 computer by Regnecentralen, particularly by Brinch-Hansen (Brinch-Hansen [1970], BrindvHansen [1973]). The objective was not to design a batch system, or a time-sharing system, or any other specific system.

Rather, the goal was to create an operating-system nucleus, or kernel, on which a complete operating system could be built. Thus, the system structure was layered, and only the lower levels—comprising the kernel—were provided. The kernel supported a collection of concurrent processes. A round-robin CPU scheduler was used. Although processes could share memory, the primary communication and synchronization mechanism was the message system provided by the kernel.

 Processes could communicate with each other by exchanging fixed-sized messages of eight words in length. All messages were stored in buffers from a common buffer pool. When a message buffer was no longer required, it was returned to the common pool. A message queue was associated with each process. It contained all the messages that had been sent to that process but had not yet been received. Messages were removed from the queue in FIFO order. The system supported four primitive operations, which were executed atomically:

These Topics Are Also In Your Syllabus
1 Atomic Transactions link
2 Programmer Interface link
You May Find Something Very Interesting Here. link
3 Introduction to Memory Management link
4 Introduction to Storage Management link
5 Introduction to Protection and Security link

• send-message (in receiver, in message, out buffer) • wait-message (out sender, out message, out buffer) • send-answer (out result, in message, in buffer) • wait-answer (out result, out message, in buffer) The last two operations allowed processes to exchange several messages at a time. These primitives required that a process service its message queue in FIFO order and that it block itself while other processes were handling its messages. To remove these restrictions, the developers provided two additional communication primitives that allowed a process to wait for the arrival of the next message or to answer and service its queue in any order: • wait-event (in previous-buffer, out next-buffer, out result) • get-event (out buffer) I/O devices were also treated as processes. The device drivers were code that converted the device interrupts and registers into messages. Thus, a process would write to a terminal by sending that terminal a message. The device driver would receive the message and output the character to the terminal. An input character would interrupt the system and transfer to 23.7 MULTICS 849 a device driver. The device driver would create a message from the^input character and send it to a waiting process.

Rating - 3/5

Rating - 3/5