2

I am reading Tanenbaum's Modern Operating Systems. I want to understand a particular concept regarding processes and blocking system calls, specifically with regards to I/O. I assume threads might complicate the discussion somewhat, so please assume that I am asking about single-threaded processes only.

The book states that when a process needs to do some I/O, it makes a system call to request the necessary data. At that point, the OS can block the process until the data is available. Specifically, the CPU waits for an interrupt from an I/O device, and upon receiving it, marks the process as ready, so that it can be picked up by the scheduler.

I appreciate the conceptual image that the book provides, but I want to understand (some of) the orchestration that goes on during this process. For example, suppose a process requests to read the file: "some_file.txt".

  • Who initiates the blocking of the process and when? Is it the system call itself, or is it the I/O device's driver?

  • Who keeps a record of what data has been asked for by which process, such as the file name, the part of the file to be read next, etc.?

peejay
  • 167
Stefan Rendevski
  • 396

2 Answers2

4

A blocking system call will simply not return control to the process that called it. Either the data will become available during the time slice that the scheduler allocated to that process, so that it will be able to execute some more instructions, or its time slice will simply expire and it gets added to the collection of known processes while still in the "Waiting for I/O" state.

In either case, it is ultimately the scheduler that decides whose code segment is allowed to execute instructions on the CPU. Non-blocking code gets to do this in somewhat regular intervals (assuming scheduling is not totally lopsided!), while blocking code will forfeit some of the time it might otherwise have had available. (This is why thread programming can yield such huge speed-ups for I/O-bound tasks.)

The record-keeping of data structures to make all this work is indeed the task of the OS, in fact I would say that it is its most fundamental task.

Kilian Foth
  • 110,899
1

The actual situation in any real operating system can actually be quite a bit more complicated than what is described by Tanenbaum. Today, "an I/O operation" could be addressed to a real, physical device ... or to some network resource ... or even to a virtual resource.

So, basically, when a process issues that system-call which serves to present a new I/O request, "the process is now 'asleep' until the request is satisfied, but it has no idea what actually happens next." The only thing it knows that "eventually it will wake up."

Most modern operating systems support the notion of "kernel threads." Yes, they are "part of the kernel," but they operate as asynchronously-scheduled "threads." On occasion, "a user-space process I/O request" might be handed-off to another "user-space process" for servicing, while the requesting process – unaware of any of this – remains blissfully asleep.

So, the process's "system call" translates to "issuing a service request" that eventually will be satisfied, whereupon the requesting process will be restarted in either a success or an error condition. None of "what happens next" is actually visible.

Mike Robinson
  • 1,821