What is meant by "blocking system call"?

Question

What is the meaning of "blocking system call"?

In my operating systems course, we are studying multithreaded programming. I'm unsure what is meant when I read in my textbook "it can allow another thread to run when a thread make a blocking system call"

Morceau

Answer 1

A blocking system call is one that must wait until the action can be completed. read() would be a good example - if no input is ready, it'll sit there and wait until some is (provided you haven't set it to non-blocking, of course, in which case it wouldn't be a blocking system call). Obviously, while one thread is waiting on a blocking system call, another thread can be off doing something else.

Ruse

is is means that when a user thread has used this blocking system call,it will wait(this thread is blocked) and another user thread can map to kernel thread which was mapped the previous ? – Morceau

I have no idea what course you are taking or what it is trying to tell you, but I would imagine so. A many-to-one multithreading model associates several user threads with a single kernel thread. If that kernel thread is in a blocking system call, then all the user threads associated with it also have to wait. This is not true with a one-to-one model, since all user threads have their own kernel thread, so if one kernel thread is blocked, another one can do something else. – Ruse

I have pretty much same question. if it is many-to-one model and if a user thread wants to make a blocking system call. Will all other threads have to stop as well? (can only kernel threads make system call?) – Knighthead

@PaulGriffiths What is the relation of blocking calls with yield points? (In the nesC paper there is an implicit relation between them in this phrase: "we would need to prohibit blocking calls in atomic sections as well as treat blocking calls as yield points for task scheduling.) – Roadhouse

@Novemberland: A yield point is a convenient place (for example, a place where it doesn't have exclusive access to a shared resource) where a task has the opportunity to voluntarily give up its execution. Usually it wants to do this before its time slice is exceeded. Since a blocking system call could be blocked for a long time, potentially far in excess of the task's time slice, entering one would be an ideal place for a yield point in a system where tasks voluntarily yield control. – Ruse

A many to one thread model can (and should) map blocking call to alternatives that don't prevent progress. But it's quite complex to get right. – Evasive

Answer 2

For a blocking system call, the caller can't do anything until the system call returns. If the system call may be lengthy (e.g. involve file IO or networking IO) this can be a bad thing (e.g. imagine a frustrated user hammering a "Cancel" button in an application that doesn't respond because that thread is blocked waiting for a packet from the network that isn't arriving). To get around that problem (to do useful work while you wait for a blocking system call to return) you can use threads - while one thread is blocked the other thread/s can continue doing useful work.

The alternative is non-blocking system calls. In this case the system call returns (almost) immediately. For lengthy system calls the result of the system call is either sent to the caller later (e.g. as some sort of event or message or signal) or polled by the caller later. This allows you to have a single thread waiting for many different lengthy system calls to complete at the same time; and avoids the hassle of threads (and locking, race conditions, the overhead of thread switches, etc). However, it also increases the hassle involved with getting and handling the system call's results.

It is (almost always) possible to write a non-blocking wrapper around a blocking system call; where the wrapper spawns a thread and returns (almost) immediately, and the spawned thread does the blocking system call and either sends the system call's results to the original caller or stores them where the original caller can poll for them.

It is also (almost always) possible to write a blocking wrapper around a non-blocking system call; where the wrapper does the system call and waits for the results before it returns.

Paduasoy

What is the relation of non-blocking system calls and split-phase operations? The second is just a small subset of the first? Is there any other kind of operations concerning non-blocking system calls? Or they are the one and the same thing? Thanks in advance! – Roadhouse

Answer 3

I would suggest having a read on this very short text: http://files.mkgnu.net/files/upstare/UPSTARE_RELEASE_0-12-8/manual/html-multi/x755.html In particular you can read there why blocking system calls can be a worry with threads, not just with concurrent processes:

This is particularly problematic for multi-threaded applications since one thread blocking on a system call may indefinitely delay the update of the code of another thread.

Hope it helps.

Toluidine

Answer 4

A blocking system call is a system call by means of which any process is requesting some service from the system but that service is not currently available. So that particular system call blocks the process.

If you want to make it clear in context with multi threading you can go through the link...

Siege

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Bobo