RE: [JBoss-dev] BasicThreadPool and Thread.stop()
Yes this is a great example of the general problem of canceling a thread
asynchronously. That resulting state is most likely not anticipated by
the thread (No one expects a = 1 to throw an exception).
Most threading APIs try to solve this problem using cancelable points.
In pthreads for example, this is any blocking thread operation (sigwait,
or pthread_join). There is also a pthread_testcancel that you can use to
programmatically check for cancellation. So the equivalent in Java is
thread.interrupt().
However, I should clarify that what I meant is that the state of the
overall system will be safe provided that the thread did not access any
shared resource. So in this scenario, while it is possible that the
thread will be corrupted, we don't care because it will eventually exit,
and all of its resources will be freed.
An example of a safe use of Thread.stop is where the target thread is
doing some long running mathematical calculation.
I am in no way, endorsing the use of thread cancellation. Even in
scenarios where it is safe to use it, the code can be easily rewritten
to periodically poll a notification variable.
-Jason
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED] On Behalf Of Adrian Brock
> Sent: Monday, February 06, 2006 3:25 AM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] BasicThreadPool and Thread.stop()
>
> Thanks for the clarification. Re-reading this:
>
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecatio
n.
> html
>
> This says it is never safe. 2 examples:
>
> lock = lock();
> // Thread death here is bad!
> try
> {
> ...
> }
> finally
> {
>lock.unlock();
> }
>
> An attempt to fix it
>
> lock = null;
> try
> {
>lock = lock();
> ...
> }
> finally
> {
>if (lock != null)
> lock.unlock();
> }
>
> But it won't work, because this code is really:
>
> lock = null;
> try
> {
>lock();
>// Thread death here is bad!
>lock = popResultFromThreadStack();
> ...
> }
> finally
> {
>if (lock != null)
> lock.unlock();
> }
> --
>
> Adrian Brock
> Chief Scientist
> JBoss Inc.
>
>
>
>
> ---
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] BasicThreadPool and Thread.stop()
On Mon, 2006-02-06 at 01:06, Jason T. Greene wrote:
> Actually the behavior you describe is the semantics of Thread.destroy()
> if it were actually implemented. Thread.stop() just forces the targeted
> thread to throw a ThreadDeath exception. This causes all finally blocks
> to execute, and in fact if a thread were to catch ThreadDeath, it could
> prevent the thread from dieing. This also causes all monitors that were
> aquired by the thread to be released. So, herein lies the problem. Since
> this exception can occur at any point, the object state of that thread
> is potentially corrupt.
>
> So, if the thread does not share state with other threads, it is
> actually quite safe. This is hardly the case though, and is a problem
> for BasicThreadPool because we do not know what the task is actually
> doing.
Thanks for the clarification. Re-reading this:
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
This says it is never safe. 2 examples:
lock = lock();
// Thread death here is bad!
try
{
...
}
finally
{
lock.unlock();
}
An attempt to fix it
lock = null;
try
{
lock = lock();
...
}
finally
{
if (lock != null)
lock.unlock();
}
But it won't work, because this code is really:
lock = null;
try
{
lock();
// Thread death here is bad!
lock = popResultFromThreadStack();
...
}
finally
{
if (lock != null)
lock.unlock();
}
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] BasicThreadPool and Thread.stop()
> Stopping the thread will avoid the cpu utilization problem,
> but your JVM is now in an unknown/unstable state.
>
> Connection c = dataSource.getConnection();
> try
> {
>synchronized (lock)
>{
> spin(); // ---> Stop
>}
> }
> finally
> {
>c.close(); // Never done
> }
>
> The connection leaks, I don't know what happens to the lock?
Actually the behavior you describe is the semantics of Thread.destroy()
if it were actually implemented. Thread.stop() just forces the targeted
thread to throw a ThreadDeath exception. This causes all finally blocks
to execute, and in fact if a thread were to catch ThreadDeath, it could
prevent the thread from dieing. This also causes all monitors that were
aquired by the thread to be released. So, herein lies the problem. Since
this exception can occur at any point, the object state of that thread
is potentially corrupt.
So, if the thread does not share state with other threads, it is
actually quite safe. This is hardly the case though, and is a problem
for BasicThreadPool because we do not know what the task is actually
doing.
This problem is not limited to Java, thread cancellation is a common
multithreaded programming issue. Sun just chose to deprecate it because
it is more than often the incorrect approach to take.
-Jason
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED] On Behalf Of Adrian Brock
> Sent: Saturday, February 04, 2006 5:15 PM
> To: jboss-development@lists.sourceforge.net
> Subject: RE: [JBoss-dev] BasicThreadPool and Thread.stop()
>
> On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
> > It was the only way I found to implement a timeout behavior that had
a
> > chance of working when there were uncooperative tasks. See the
> > org.jboss.test.util.test.
> > ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
> > example.
>
> There is no real solution to that problem in java.
> CPU loops don't respond to thread interrupts.
>
> You can't even redefineClass() to add a
> Thread.interrupted()
> check in the misbehaving method, because it won't take affect on that
> invocation.
>
> Stopping the thread will avoid the cpu utilization problem,
> but your JVM is now in an unknown/unstable state.
>
> Connection c = dataSource.getConnection();
> try
> {
>synchronized (lock)
>{
> spin(); // ---> Stop
>}
> }
> finally
> {
>c.close(); // Never done
> }
>
> The connection leaks, I don't know what happens to the lock?
>
> A better solution would be to "automatically" trigger a reboot if you
> detect a misbehaving thread.
>
> >
> > -----Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Adrian Brock
> > Sent: Saturday, February 04, 2006 2:33 PM
> > To: jboss-development@lists.sourceforge.net
> > Subject: [JBoss-dev] BasicThreadPool and Thread.stop()
> >
> > I don't think it is a good idea to invoke Thread.stop().
> > This has memory leak problems.
> >
> > Why was this introduced? The pooled threads are already daemon
threads
> > so they should not stop the system from exiting at shutdown.
> >
> > If you are not shutting down the system, then any objects
> > on the stopped thread's stack are not garbage collected.
> --
>
> Adrian Brock
> Chief Scientist
> JBoss Inc.
>
>
>
>
> ---
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> ___
> JBoss-Development mailing list
> JBoss-Development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] BasicThreadPool and Thread.stop()
This sounds like a good blog:
"Sun, we want fixes not new features"
Talk about this thread problem as well as the serialization problems.
Adrian Brock wrote:
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a timeout behavior that had a
chance of working when there were uncooperative tasks. See the
org.jboss.test.util.test.
ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
example.
There is no real solution to that problem in java.
CPU loops don't respond to thread interrupts.
You can't even redefineClass() to add a
Thread.interrupted()
check in the misbehaving method, because it won't take affect on that
invocation.
Stopping the thread will avoid the cpu utilization problem,
but your JVM is now in an unknown/unstable state.
Connection c = dataSource.getConnection();
try
{
synchronized (lock)
{
spin(); // ---> Stop
}
}
finally
{
c.close(); // Never done
}
The connection leaks, I don't know what happens to the lock?
A better solution would be to "automatically" trigger a reboot if you
detect a misbehaving thread.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Saturday, February 04, 2006 2:33 PM
To: jboss-development@lists.sourceforge.net
Subject: [JBoss-dev] BasicThreadPool and Thread.stop()
I don't think it is a good idea to invoke Thread.stop().
This has memory leak problems.
Why was this introduced? The pooled threads are already daemon threads
so they should not stop the system from exiting at shutdown.
If you are not shutting down the system, then any objects
on the stopped thread's stack are not garbage collected.
--
Bill Burke
Chief Architect
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] BasicThreadPool and Thread.stop()
Its kind of sad there is no solution to this after all of this time.
Gosh Java sucks... ;-) I'm sure it all works perfectly in NuFuBarX
lang...we must migrate JBoss immediately.
Adrian Brock wrote:
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
It was the only way I found to implement a timeout behavior that had a
chance of working when there were uncooperative tasks. See the
org.jboss.test.util.test.
ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
example.
There is no real solution to that problem in java.
CPU loops don't respond to thread interrupts.
You can't even redefineClass() to add a
Thread.interrupted()
check in the misbehaving method, because it won't take affect on that
invocation.
Stopping the thread will avoid the cpu utilization problem,
but your JVM is now in an unknown/unstable state.
Connection c = dataSource.getConnection();
try
{
synchronized (lock)
{
spin(); // ---> Stop
}
}
finally
{
c.close(); // Never done
}
The connection leaks, I don't know what happens to the lock?
A better solution would be to "automatically" trigger a reboot if you
detect a misbehaving thread.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Saturday, February 04, 2006 2:33 PM
To: jboss-development@lists.sourceforge.net
Subject: [JBoss-dev] BasicThreadPool and Thread.stop()
I don't think it is a good idea to invoke Thread.stop().
This has memory leak problems.
Why was this introduced? The pooled threads are already daemon threads
so they should not stop the system from exiting at shutdown.
If you are not shutting down the system, then any objects
on the stopped thread's stack are not garbage collected.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] BasicThreadPool and Thread.stop()
On Sat, 2006-02-04 at 17:44, Scott M Stark wrote:
> It was the only way I found to implement a timeout behavior that had a
> chance of working when there were uncooperative tasks. See the
> org.jboss.test.util.test.
> ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an
> example.
There is no real solution to that problem in java.
CPU loops don't respond to thread interrupts.
You can't even redefineClass() to add a
Thread.interrupted()
check in the misbehaving method, because it won't take affect on that
invocation.
Stopping the thread will avoid the cpu utilization problem,
but your JVM is now in an unknown/unstable state.
Connection c = dataSource.getConnection();
try
{
synchronized (lock)
{
spin(); // ---> Stop
}
}
finally
{
c.close(); // Never done
}
The connection leaks, I don't know what happens to the lock?
A better solution would be to "automatically" trigger a reboot if you
detect a misbehaving thread.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Adrian Brock
> Sent: Saturday, February 04, 2006 2:33 PM
> To: jboss-development@lists.sourceforge.net
> Subject: [JBoss-dev] BasicThreadPool and Thread.stop()
>
> I don't think it is a good idea to invoke Thread.stop().
> This has memory leak problems.
>
> Why was this introduced? The pooled threads are already daemon threads
> so they should not stop the system from exiting at shutdown.
>
> If you are not shutting down the system, then any objects
> on the stopped thread's stack are not garbage collected.
--
Adrian Brock
Chief Scientist
JBoss Inc.
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] BasicThreadPool and Thread.stop()
It was the only way I found to implement a timeout behavior that had a chance of working when there were uncooperative tasks. See the org.jboss.test.util.test. ThreadPoolTaskUnitTestCase.testCompleteTimeoutWithSpinLoop as an example. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Saturday, February 04, 2006 2:33 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] BasicThreadPool and Thread.stop() I don't think it is a good idea to invoke Thread.stop(). This has memory leak problems. Why was this introduced? The pooled threads are already daemon threads so they should not stop the system from exiting at shutdown. If you are not shutting down the system, then any objects on the stopped thread's stack are not garbage collected. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] BasicThreadPool and Thread.stop()
I don't think it is a good idea to invoke Thread.stop(). This has memory leak problems. Why was this introduced? The pooled threads are already daemon threads so they should not stop the system from exiting at shutdown. If you are not shutting down the system, then any objects on the stopped thread's stack are not garbage collected. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
