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.?

  • 1
    Isn't this the same question as you posted over the weekend? Commented Oct 3, 2022 at 8:55
  • Yes, albeit trimmed, because it was deemed that the question needed more focus. Commented Oct 3, 2022 at 9:05

2 Answers 2


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.

  • if I understand the first paragraph correctly, assuming requested data does not arrive within the process' allocated time slot, the remainder of that time slot will effectively be wasted? Commented Oct 3, 2022 at 12:12
  • 1
    Yes, if your control flow cannot proceed without the external data, then you effectively waste the rest of your time slice. (Yielding your time slice early might earn you credit from the scheduler to be treated favorably on further wakeups, but either way, I/O waiting massively increases your wallclock time.) Commented Oct 3, 2022 at 12:51
  • Is the scheduler able to force a process to yield in that case, or must this be handled explicitly by the process's thread? Commented Oct 3, 2022 at 13:22
  • No, by calling a blocking system call, you implicitly accept that you might never (in this round) wake up again :-) Commented Oct 3, 2022 at 13:25

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.