Java: stopping a thread with no synchronization

Question

TL;DR Is it OK to a Java thread when I know it isn't synchronized to anything else?

First I'll describe my predicament. I have a service that handles requests from an app (both on the same machine). This service is single threaded. In some cases, answering requests can take a while. I'd like to time out the request in those cases. Sadly, it's quite complicated to poll interrupts inside said service, as it has quite expansive algorithmic logic, and would cause lots of ugly code rewriting.

Think of the service as a facade that calls a library of scary algorithmic stuff. Currently the service simply calls the library upon request, I want it to start a thread, and time it out if computation takes too long. I intend on using just a single extra thread.

I read How do you kill a thread in Java? and https://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

According to these, stopping a thread is deprecated because of loss of synchronization. However, my service is basically single threaded, and thus has no need for synchronization.

In this case, is it OK for me to stop the thread? Am I missing some internal java stuff?

Thanks!

Answer 1

So you have a service that processes requests, and sometimes that processing can take a while. You want to impose some maximum amount of time your service could spend processing that request before giving up.

You don't want to litter your code with checks to a flag that would be set by some interrupt, because the code is large and complicated.

Your options:

1. Don't give up.

Process each request on a separate thread. Allow each request to run to completion, taking as much time as necessary. Consider improving the service request code, perhaps using parallelism, to reduce the amount of time it takes to run.

2. Litter your code with 'time to stop' checks.

This is the second best answer - you have controlled access over where your program decides to stop processing the response. Your program can controllably shut down the request processing, properly cleaning up whatever it needs to (perhaps open resources such as files, sockets, etc; resetting program state internally).

3. Kill the thread.

Calling Thread.stop() is deprecated, and for good reason - it can corrupt synchronization state. If your request handling logic uses any form of synchronization, then you'll cause corruption. Keep in mind that synchronization is used everywhere, even if you don't see it. Reading from a file uses a form of synchronization. Writing to the standard out uses synchronization.

This is possible, but it's a terrible idea.

...

There are other strategies related to #2 - for instance, you could restructure your program so that each section of processing is created as a job on a queue, that one thread is responsible for dequeuing and executing - basically, the message pump pattern. In this design, you'd have a nice choke point at which to put your 'timed out' logic. This is the design used by most windowing frameworks - the UI message pump.