3 ms·
That seems a necessary but not sufficient condition, since a pre-emptively multitasking OS may do this after almost any instruction. Not only that, but any OS
by akoboldfrying 2y ago
That seems a necessary but not sufficient condition, since a pre-emptively multitasking OS may do this after almost any instruction.
Not only that, but any OS with virtual memory will almost certainly context-switch on a hard page fault (and perhaps even on a soft page fault, I don't know). So it would seem that teading memory is sufficient to be "blocking", by your criterion.
- PaulDavisThe1st 2y ago1) I deliberately left it open to including page faults by design. If you do not understand that reading memory might lead to your process blocking, you have much to learn as a programmer. However, I would concede that that this is not really part of the normal meaning of "blocking", despite the result being very similar. 2) I did not intend to include preemption. I should reword it to make it clear that the "condition" must be something of the process' own making (e.g. reading from a file or a socket) rather than simply an arbitrary decision by the kernel.
- gpderetta 2y agoWould signaling, say, a semaphore count? That could cause another higher priority realtime process to wake-up and block the signaler forever. I think the canonical meaning of "blocking code" is more of the "I know it when I see it" variety than an useful and rigorous definition.