Extend Thread to test proper termination with join?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Java Concurrency In Practice, 12.1.2. Testing Blocking Operations:
void testTakeBlocksWhenEmpty() {
final BoundedBuffer<Integer> bb = new BoundedBuffer<Integer>(10);
Thread taker = new Thread() {
public void run() {
try {
int unused = bb.take();
fail(); // if we get here, it’s an error
} catch (InterruptedException success) { }
}
};
try {
taker.start();
Thread.sleep(LOCKUP_DETECT_TIMEOUT);
taker.interrupt();
taker.join(LOCKUP_DETECT_TIMEOUT);
assertFalse(taker.isAlive());
} catch (Exception unexpected) {
fail();
}
}
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join. The same approach can be used to
test that the taker thread unblocks after an element is placed in the
queue by the main thread.
But I don't see how extending Thread helps with testing that. For me it seems that the same test could be done with passing Runnable to Thread. Can somebody explain that?
java multithreading concurrency
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
add a comment |
Java Concurrency In Practice, 12.1.2. Testing Blocking Operations:
void testTakeBlocksWhenEmpty() {
final BoundedBuffer<Integer> bb = new BoundedBuffer<Integer>(10);
Thread taker = new Thread() {
public void run() {
try {
int unused = bb.take();
fail(); // if we get here, it’s an error
} catch (InterruptedException success) { }
}
};
try {
taker.start();
Thread.sleep(LOCKUP_DETECT_TIMEOUT);
taker.interrupt();
taker.join(LOCKUP_DETECT_TIMEOUT);
assertFalse(taker.isAlive());
} catch (Exception unexpected) {
fail();
}
}
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join. The same approach can be used to
test that the taker thread unblocks after an element is placed in the
queue by the main thread.
But I don't see how extending Thread helps with testing that. For me it seems that the same test could be done with passing Runnable to Thread. Can somebody explain that?
java multithreading concurrency
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
Note: thefail()won't cause the test to fail. It will print an error, but the test will pass. BTW If you don't catch a thrownExceptionin a test it fails anyway, but you get to see why rather than a genericAssertionError.
– Peter Lawrey
Nov 16 '18 at 17:33
@PeterLawrey Yes, I noticed this code is not perfect and just to make sure we're on the same page, this is code from the book, not mine. ; )
– ctomek
Nov 16 '18 at 17:41
1
The quote says, "...instead of using a Runnable in a pool." Maybe it's talking about the appropriateness of directly creating aThreadinstance instead of letting a thread pool object or a factory object do it.
– Solomon Slow
Nov 16 '18 at 18:35
add a comment |
Java Concurrency In Practice, 12.1.2. Testing Blocking Operations:
void testTakeBlocksWhenEmpty() {
final BoundedBuffer<Integer> bb = new BoundedBuffer<Integer>(10);
Thread taker = new Thread() {
public void run() {
try {
int unused = bb.take();
fail(); // if we get here, it’s an error
} catch (InterruptedException success) { }
}
};
try {
taker.start();
Thread.sleep(LOCKUP_DETECT_TIMEOUT);
taker.interrupt();
taker.join(LOCKUP_DETECT_TIMEOUT);
assertFalse(taker.isAlive());
} catch (Exception unexpected) {
fail();
}
}
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join. The same approach can be used to
test that the taker thread unblocks after an element is placed in the
queue by the main thread.
But I don't see how extending Thread helps with testing that. For me it seems that the same test could be done with passing Runnable to Thread. Can somebody explain that?
java multithreading concurrency
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
Java Concurrency In Practice, 12.1.2. Testing Blocking Operations:
void testTakeBlocksWhenEmpty() {
final BoundedBuffer<Integer> bb = new BoundedBuffer<Integer>(10);
Thread taker = new Thread() {
public void run() {
try {
int unused = bb.take();
fail(); // if we get here, it’s an error
} catch (InterruptedException success) { }
}
};
try {
taker.start();
Thread.sleep(LOCKUP_DETECT_TIMEOUT);
taker.interrupt();
taker.join(LOCKUP_DETECT_TIMEOUT);
assertFalse(taker.isAlive());
} catch (Exception unexpected) {
fail();
}
}
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join. The same approach can be used to
test that the taker thread unblocks after an element is placed in the
queue by the main thread.
But I don't see how extending Thread helps with testing that. For me it seems that the same test could be done with passing Runnable to Thread. Can somebody explain that?
java multithreading concurrency
java multithreading concurrency
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
asked Nov 16 '18 at 17:08
ctomekctomek
1,0031020
1,0031020
Note: thefail()won't cause the test to fail. It will print an error, but the test will pass. BTW If you don't catch a thrownExceptionin a test it fails anyway, but you get to see why rather than a genericAssertionError.
– Peter Lawrey
Nov 16 '18 at 17:33
@PeterLawrey Yes, I noticed this code is not perfect and just to make sure we're on the same page, this is code from the book, not mine. ; )
– ctomek
Nov 16 '18 at 17:41
1
The quote says, "...instead of using a Runnable in a pool." Maybe it's talking about the appropriateness of directly creating aThreadinstance instead of letting a thread pool object or a factory object do it.
– Solomon Slow
Nov 16 '18 at 18:35
add a comment |
Note: thefail()won't cause the test to fail. It will print an error, but the test will pass. BTW If you don't catch a thrownExceptionin a test it fails anyway, but you get to see why rather than a genericAssertionError.
– Peter Lawrey
Nov 16 '18 at 17:33
@PeterLawrey Yes, I noticed this code is not perfect and just to make sure we're on the same page, this is code from the book, not mine. ; )
– ctomek
Nov 16 '18 at 17:41
1
The quote says, "...instead of using a Runnable in a pool." Maybe it's talking about the appropriateness of directly creating aThreadinstance instead of letting a thread pool object or a factory object do it.
– Solomon Slow
Nov 16 '18 at 18:35
Note: the
fail() won't cause the test to fail. It will print an error, but the test will pass. BTW If you don't catch a thrown Exception in a test it fails anyway, but you get to see why rather than a generic AssertionError.– Peter Lawrey
Nov 16 '18 at 17:33
Note: the
fail() won't cause the test to fail. It will print an error, but the test will pass. BTW If you don't catch a thrown Exception in a test it fails anyway, but you get to see why rather than a generic AssertionError.– Peter Lawrey
Nov 16 '18 at 17:33
@PeterLawrey Yes, I noticed this code is not perfect and just to make sure we're on the same page, this is code from the book, not mine. ; )
– ctomek
Nov 16 '18 at 17:41
@PeterLawrey Yes, I noticed this code is not perfect and just to make sure we're on the same page, this is code from the book, not mine. ; )
– ctomek
Nov 16 '18 at 17:41
1
1
The quote says, "...instead of using a Runnable in a pool." Maybe it's talking about the appropriateness of directly creating a
Thread instance instead of letting a thread pool object or a factory object do it.– Solomon Slow
Nov 16 '18 at 18:35
The quote says, "...instead of using a Runnable in a pool." Maybe it's talking about the appropriateness of directly creating a
Thread instance instead of letting a thread pool object or a factory object do it.– Solomon Slow
Nov 16 '18 at 18:35
add a comment |
1 Answer
1
active
oldest
votes
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join.
In other words that approach lets you a chance to interrupt the test thread and join it to make sure it has been terminated properly. You can't handle threads in that way if you use, for example - ThreadPoolExecutor class.
Also, it is OK to create a new thread, initiating it with Runnable, like Thread taker = new Thread(() -> {...});. Remember that the book was written about 8 years ago, and creating Runnable instead of subclass of Thread would make that example a bit longer.
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
add a comment |
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%2f53342444%2fextend-thread-to-test-proper-termination-with-join%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join.
In other words that approach lets you a chance to interrupt the test thread and join it to make sure it has been terminated properly. You can't handle threads in that way if you use, for example - ThreadPoolExecutor class.
Also, it is OK to create a new thread, initiating it with Runnable, like Thread taker = new Thread(() -> {...});. Remember that the book was written about 8 years ago, and creating Runnable instead of subclass of Thread would make that example a bit longer.
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
add a comment |
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join.
In other words that approach lets you a chance to interrupt the test thread and join it to make sure it has been terminated properly. You can't handle threads in that way if you use, for example - ThreadPoolExecutor class.
Also, it is OK to create a new thread, initiating it with Runnable, like Thread taker = new Thread(() -> {...});. Remember that the book was written about 8 years ago, and creating Runnable instead of subclass of Thread would make that example a bit longer.
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
add a comment |
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join.
In other words that approach lets you a chance to interrupt the test thread and join it to make sure it has been terminated properly. You can't handle threads in that way if you use, for example - ThreadPoolExecutor class.
Also, it is OK to create a new thread, initiating it with Runnable, like Thread taker = new Thread(() -> {...});. Remember that the book was written about 8 years ago, and creating Runnable instead of subclass of Thread would make that example a bit longer.
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
This is one of the few cases in which it is appropriate to subclass
Thread explicitly instead of using a Runnable in a pool: in order to
test proper termination with join.
In other words that approach lets you a chance to interrupt the test thread and join it to make sure it has been terminated properly. You can't handle threads in that way if you use, for example - ThreadPoolExecutor class.
Also, it is OK to create a new thread, initiating it with Runnable, like Thread taker = new Thread(() -> {...});. Remember that the book was written about 8 years ago, and creating Runnable instead of subclass of Thread would make that example a bit longer.
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
answered Nov 18 '18 at 11:53
Aleksandr SemyannikovAleksandr Semyannikov
593217
593217
add a comment |
add a comment |
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%2f53342444%2fextend-thread-to-test-proper-termination-with-join%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
Note: the
fail()won't cause the test to fail. It will print an error, but the test will pass. BTW If you don't catch a thrownExceptionin a test it fails anyway, but you get to see why rather than a genericAssertionError.– Peter Lawrey
Nov 16 '18 at 17:33
@PeterLawrey Yes, I noticed this code is not perfect and just to make sure we're on the same page, this is code from the book, not mine. ; )
– ctomek
Nov 16 '18 at 17:41
1
The quote says, "...instead of using a Runnable in a pool." Maybe it's talking about the appropriateness of directly creating a
Threadinstance instead of letting a thread pool object or a factory object do it.– Solomon Slow
Nov 16 '18 at 18:35