Non-cooperative Thread.stop() alternative in modern Android

user_13950559 0
Viewed 102

Thread.stop() is now removed from modern Android API. From https://developer.android.com/reference/java/lang/Thread#stop(),

Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, ...

I suppose that a complete removal of a method must be backed by an alternative of it, both for the many uses where it is replaceable, and for the many other uses where it is not. I am therefore wondering what is the alternative of Thread.stop() that stops a thread where cooperative interruption flags do not work, which is possibly due to e.g. calls of slow 3rd-party functions.

From the articles I've googled and the duplicated SO questions I've read about this issue, I got only two unsatisfactory types of answers:

  1. You should just consider cooperative interruption because it's not stupid.
  2. Thread.stop() is now gone for whatever reason so just forget it.

I would appreciate a lot if you could either provide a functioning alternative of Thread.stop() or explain the rationale behind removing it despite the legitimate use cases depending on it, where "legitimate" implies nonexistence of any synchronization and locking issue.

Thanks in advance.

multithreading android java
1 Answers

There is no "modern" alternative. The old alternatives are still the only ones. Why? Because this is fundamentally an unsolvable problem1 ... if the threads are not cooperating or if are able to correctly unpick things when they field an interrupt.

For the record, the technical reasons that Thread.stop() is unsafe include:

  • It breaks mutual exclusion locks help by the thread being stopped. This may leave the object that was locked ... or other objects ... in an inconsistent state.
  • It may result in broken inter-thread signalling. For example, if a thread is expected to notify a condition variable, and it gets stopped before this happen, then other threads may be stuck forever waiting for a notify that never arrives.

If has said that issues such as the above can in theory be addressed by application code on a case-by-base basis by catching ThreadDeath and taking remedial action. But to borrow someone else's words, "it would be insanely messy".

I'm sorry if you think this is all unsatisfactory. But this is life. If you cannot write your threads to be cooperative, and you need them to be killable, run them in an external process, via Process etcetera.

Now ... if we could wave a magic wand and replace Java threads with a CSP-like model of concurrency (and eschew state sharing between processes), then the problem goes away. Though now you have to deal with the other problem of what to do with the messages queued up when a process is terminated. But at least that is a tractable problem.

1 - I am asserting this without proof! However, if it was a solvable problem, then you would have thought that Sun or Oracle or Google would have discovered and implemented a solution in the last ... umm ... 25 years. Challenge: If you can come up with a viable implementation model for safely killing Java threads, I expect that certain companies would be willing to offer you a very well-paid job. Especially if they can secure exclusive rights on your patent.

user_1399850
Related