Can low priority I/O threads block the high priority threads?
I am following the book CLR via C# by Jeffrey Richter. With regards to I/O request priorities it says:
Because I/O requests typically require time to process, it is possible that a
low-priority thread could significantly affect the responsiveness of the system by suspending
high-priority threads, which prevents them from getting their work done
However, Microsoft's documentation about Scheduling Threads states that:
If a higher priority thread becomes runnable, the lower priority thread is preempted and the higher priority thread is allowed to execute once again
Even Jeff's own book states the following about thread scheduling:
Higher-priority threads always preempt lower-priority threads, regardless of what the lower-priority
threads are executing. For example, if a priority 5 thread is running and the system determines that a
higher-priority thread is ready to run, the system immediately suspends the lower-priority thread (even
if it’s in the middle of its time-slice) and assigns the CPU to the higher-priority thread, which gets a full
time-slice.
Based on the above, I understand that whenever a low priority thread performing I/O operation is running and a higher priority thread is in the runnable state, the higher priority thread is executed suspending the I/O thread temporarily. How is it possible for the low priority I/O threads to suspend the high priority threads?
.net multithreading clr
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
add a comment |
I am following the book CLR via C# by Jeffrey Richter. With regards to I/O request priorities it says:
Because I/O requests typically require time to process, it is possible that a
low-priority thread could significantly affect the responsiveness of the system by suspending
high-priority threads, which prevents them from getting their work done
However, Microsoft's documentation about Scheduling Threads states that:
If a higher priority thread becomes runnable, the lower priority thread is preempted and the higher priority thread is allowed to execute once again
Even Jeff's own book states the following about thread scheduling:
Higher-priority threads always preempt lower-priority threads, regardless of what the lower-priority
threads are executing. For example, if a priority 5 thread is running and the system determines that a
higher-priority thread is ready to run, the system immediately suspends the lower-priority thread (even
if it’s in the middle of its time-slice) and assigns the CPU to the higher-priority thread, which gets a full
time-slice.
Based on the above, I understand that whenever a low priority thread performing I/O operation is running and a higher priority thread is in the runnable state, the higher priority thread is executed suspending the I/O thread temporarily. How is it possible for the low priority I/O threads to suspend the high priority threads?
.net multithreading clr
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
It is specific to I/O, not the rest you mention. An example would be the disk driver, it must serialize access to the disk. If a low priority thread gets a large read request started then the high priority thread can't get serviced for a while if wants to read as well. It is just not much of an issue, a high priority thread should not do I/O. Other threads can do that and notify the high priority thread that data is available. It already largely works that way when you use async code.
– Hans Passant
Nov 25 '18 at 23:03
Makes sense...Could you write this as an answer so that I can mark it as the correct answer?
– Piyush Saravagi
Nov 26 '18 at 5:03
add a comment |
I am following the book CLR via C# by Jeffrey Richter. With regards to I/O request priorities it says:
Because I/O requests typically require time to process, it is possible that a
low-priority thread could significantly affect the responsiveness of the system by suspending
high-priority threads, which prevents them from getting their work done
However, Microsoft's documentation about Scheduling Threads states that:
If a higher priority thread becomes runnable, the lower priority thread is preempted and the higher priority thread is allowed to execute once again
Even Jeff's own book states the following about thread scheduling:
Higher-priority threads always preempt lower-priority threads, regardless of what the lower-priority
threads are executing. For example, if a priority 5 thread is running and the system determines that a
higher-priority thread is ready to run, the system immediately suspends the lower-priority thread (even
if it’s in the middle of its time-slice) and assigns the CPU to the higher-priority thread, which gets a full
time-slice.
Based on the above, I understand that whenever a low priority thread performing I/O operation is running and a higher priority thread is in the runnable state, the higher priority thread is executed suspending the I/O thread temporarily. How is it possible for the low priority I/O threads to suspend the high priority threads?
.net multithreading clr
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
I am following the book CLR via C# by Jeffrey Richter. With regards to I/O request priorities it says:
Because I/O requests typically require time to process, it is possible that a
low-priority thread could significantly affect the responsiveness of the system by suspending
high-priority threads, which prevents them from getting their work done
However, Microsoft's documentation about Scheduling Threads states that:
If a higher priority thread becomes runnable, the lower priority thread is preempted and the higher priority thread is allowed to execute once again
Even Jeff's own book states the following about thread scheduling:
Higher-priority threads always preempt lower-priority threads, regardless of what the lower-priority
threads are executing. For example, if a priority 5 thread is running and the system determines that a
higher-priority thread is ready to run, the system immediately suspends the lower-priority thread (even
if it’s in the middle of its time-slice) and assigns the CPU to the higher-priority thread, which gets a full
time-slice.
Based on the above, I understand that whenever a low priority thread performing I/O operation is running and a higher priority thread is in the runnable state, the higher priority thread is executed suspending the I/O thread temporarily. How is it possible for the low priority I/O threads to suspend the high priority threads?
.net multithreading clr
.net multithreading clr
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
asked Nov 25 '18 at 21:21
Piyush SaravagiPiyush Saravagi
1647
1647
It is specific to I/O, not the rest you mention. An example would be the disk driver, it must serialize access to the disk. If a low priority thread gets a large read request started then the high priority thread can't get serviced for a while if wants to read as well. It is just not much of an issue, a high priority thread should not do I/O. Other threads can do that and notify the high priority thread that data is available. It already largely works that way when you use async code.
– Hans Passant
Nov 25 '18 at 23:03
Makes sense...Could you write this as an answer so that I can mark it as the correct answer?
– Piyush Saravagi
Nov 26 '18 at 5:03
add a comment |
It is specific to I/O, not the rest you mention. An example would be the disk driver, it must serialize access to the disk. If a low priority thread gets a large read request started then the high priority thread can't get serviced for a while if wants to read as well. It is just not much of an issue, a high priority thread should not do I/O. Other threads can do that and notify the high priority thread that data is available. It already largely works that way when you use async code.
– Hans Passant
Nov 25 '18 at 23:03
Makes sense...Could you write this as an answer so that I can mark it as the correct answer?
– Piyush Saravagi
Nov 26 '18 at 5:03
It is specific to I/O, not the rest you mention. An example would be the disk driver, it must serialize access to the disk. If a low priority thread gets a large read request started then the high priority thread can't get serviced for a while if wants to read as well. It is just not much of an issue, a high priority thread should not do I/O. Other threads can do that and notify the high priority thread that data is available. It already largely works that way when you use async code.
– Hans Passant
Nov 25 '18 at 23:03
It is specific to I/O, not the rest you mention. An example would be the disk driver, it must serialize access to the disk. If a low priority thread gets a large read request started then the high priority thread can't get serviced for a while if wants to read as well. It is just not much of an issue, a high priority thread should not do I/O. Other threads can do that and notify the high priority thread that data is available. It already largely works that way when you use async code.
– Hans Passant
Nov 25 '18 at 23:03
Makes sense...Could you write this as an answer so that I can mark it as the correct answer?
– Piyush Saravagi
Nov 26 '18 at 5:03
Makes sense...Could you write this as an answer so that I can mark it as the correct answer?
– Piyush Saravagi
Nov 26 '18 at 5:03
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53472118%2fcan-low-priority-i-o-threads-block-the-high-priority-threads%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53472118%2fcan-low-priority-i-o-threads-block-the-high-priority-threads%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It is specific to I/O, not the rest you mention. An example would be the disk driver, it must serialize access to the disk. If a low priority thread gets a large read request started then the high priority thread can't get serviced for a while if wants to read as well. It is just not much of an issue, a high priority thread should not do I/O. Other threads can do that and notify the high priority thread that data is available. It already largely works that way when you use async code.
– Hans Passant
Nov 25 '18 at 23:03
Makes sense...Could you write this as an answer so that I can mark it as the correct answer?
– Piyush Saravagi
Nov 26 '18 at 5:03