Talk:Blocking (computing)

merge

I suggest merging blocking (scheduling) into blocking (computing). The two articles are nearly stubs now, and I think a single article can cover these two very closely related terms. --68.0.124.33 (talk) 15:37, 17 February 2009 (UTC)

I merged the scheduling article into this one, since this one seems to have got a bit more love according to its history. Vadmium (talk) 06:52, 15 September 2011 (UTC).

Removed paragraph

I removed the following:

"In a hypothetical two-state (running and not-running) model, processes would go onto the ready queue before being dispatched for execution. In the absence of a blocked state, if priority is measured by holdup time, blocked processes would erroneously get scheduled despite having nothing to operate on. This is undesirable due to inefficient processor usage. Hence the efficient use of resources makes a case for a blocked queue in which processes line up until the event dependency resolves."

This doesn't make a lot of sense, since a process in the not-ready queue could be flagged as blocked and not scheduled for execution. Having a separate queue for blocked processes is just a performance consideration. Priority is mostly irrelevant here. Peter Flass (talk) 14:36, 27 April 2014 (UTC)

"Blocking" as a rag that's red on one side and green on the other

I have tried to explain that "blocking" in one camp is seen as "evil", but in another camp it has little rating along the evil-good axis. It's just part of what one learns when programming with, f.ex. channels. I wonder if it would be ok to describe a little more of this and refer to a private blog note: http://www.teigfam.net/oyvind/home/technology/092-not-so-blocking-after-all. I have made a figure in there, but most importanly there is a copy of a thread at occam-com called The history of the term "to block on a channel" with comments by persons like f.ex. David May --Øyvind Teig (talk) 20:37, 4 October 2014 (UTC)

Passive blocking waits are not in general "part of the semantics of channels"

An example is "blocking on a channel" where passively waiting for the other part (no polling or spin loop) is part of the semantics of channels.

This is making a lot of assumptions that are not true of many designs for channels.

The context of the article is any computing system that uses blocking, and the link for "channel" is to Channel (programming). Even restricting to channels as a programming language abstraction (either built-in or provided by a library), there is a huge range of possible semantics. But the reference is specifically about channels in Go, which is not enough to support the general statement.

The statement is also mixing implementation ("no spin loop") with semantics. Incidentally, even the channels in Google's implementation of Go do have a lock that makes use of a spin loop. And all we can say about polling is that a blocking operation doesn't involve explicit polling in the program, whether or not polling is done behind the scenes.

The statement is also assuming that blocking semantics is associated with a channel, rather than with the operation used to read from or write to it. Many systems provide both blocking and non-blocking communication even on the same channel, via different language constructs or APIs. Actually Go is one of those systems, via the select construct. Daira Hopwood ⚥ (talk) 11:59, 22 September 2023 (UTC)

References