Question

I know the accepted, correct solutions for gracefully closing a thread.

But assume my game is supposed to be fault-tolerant, and when a new gamegplay is started, it tries to gracefully close the (now-paused) thread of the old gameplay. If it fails to join it / close it (e.g. because the old thread is buggy and is in an infinite loop), it instantiates the new Thread and starts it. But I don’t like the fact that the old thread is still there, eating resources.

Is there an accepted way to kill an unresponsive thread without killing the process? It seems to me there isn’t, in fact, I read somewhere that a Thread might not react to Thread.stop() either.

So there is no way dealing with a thread in an infinite loop (e.g. due to a bug), is it? Even if it reacts to Thread.stop(), the docs say that Thread.stop() may leave Dalvik VM in an inconsistent state…

Answer 1

If you need this capability, you must design it and implement it. Obviously, if you don’t design and implement a graceful way to shut down a thread, then there will be no way to gracefully shut down a thread. There is no generic solution because the solution is application-specific. For example, it depends on what resources the thread might hold and what shared state the thread may hold locks on or have corrupted.

The canonical answer is this: If you need this capability, don’t use threads. Use processes.

The core reason is the way threads work. You acquire a lock and then you manipulate shared data. While you’re manipulating that shared data, it can enter an inconsistent state. It is the absolute responsibility of a thread to restore the data to a consistent state before releasing the lock. (Consider, for example, deleting an object from a doubly-linked list. You must adjust the forward link or the reverse link first. In between those two operations, the linked-list is in an inconsistent state.)

Say you have this code:

1. Acquire a lock or enter a synchronized block.

2. Begin modifying the shared state the lock protects.

3. Bug

4. Return the data the lock protects to a consistent state.

5. Release the lock.

So, now, what do we do? At step 3, the thread holds a lock and it has encountered a bug and triggered an exception. If we don’t release the lock it acquired in step 1, every thread that tries to acquire that same lock will wait forever, and we’re doomed. If we do release the lock it acquired in step 1, every thread that acquires the lock will then see the inconsistent shared state the thread failed to clean up because it never got to step 4. Either way, we’re doomed.

If a thread encounters an exceptional condition the application programmer did not create a sane way to handle, the process is doomed.