-1

I like the fact that threads can share some resources but they need to release their private resources in the end. Meantime, some computations may be obsolete and you kill them, using Task Manager. I am looking for the same thing done in one JVM process.

You say that thread.stop is unreliable and propose that my thread polls the interrupted flag instead. But, polling is not efficient, right? You do not want neither performance penalty nor polluting your code with ubiquitous if (interrupted) blocks. What is going to be the best appropriate option here?

Community
  • 1
  • 1
Little Alien
  • 1
  • 8
  • 22
  • Can you prove that polling is inefficient? Or are you just assuming it is? – biziclop May 13 '16 at 13:10
  • If you think that inserting `check(flag)` everywhere is efficient, I am assuming it. – Little Alien May 13 '16 at 13:16
  • 2
    I tend to measure rather than assume. It brings better results. There is of course no need to put checks everywhere either, the flag is automatically checked whenever you do I/O or sleep/wait. And if you do none of these, it's still a simple trade-off between how responsive you want stopping to be and how many times you want to check the flag. (Usually it doesn't matter how fast the thread stops, so one check per main loop is enough.) – biziclop May 13 '16 at 13:39
  • I do not understand why did all OS vendors migrated to the `preemptive multitasking` if I am wrong and `cooperative multitasking` is that great. – Little Alien May 13 '16 at 13:49
  • I think you're confusing concepts a bit. Pre-emptive multitasking is a completely different concept from signalling, which is what most OS-es use to stop processes. So where are your benchmarks that show polling to be unacceptably inefficient in your specific case? – biziclop May 13 '16 at 13:55
  • Sure. Signaling and preemption is used for processes. I am applying it to the threads. This makes them completely different things. I do not understand why am I equating cooperative multitasking with polling and preemptive process eviction with killing a process. This are obviously different things. Preemptive multitasking may be more efficient than cooperative polling but this cannot be applied to the thread signaling mechanism that I am asking for. I often lose the self moderation when drawing the parallels. Thanks for snubbing me. – Little Alien May 13 '16 at 14:20
  • I'm not snubbing you, I'm trying to help. Because there is currently no safe way of doing what you want in Java, but neither is it needed in most scenarios. You seem to have set up a false premise that signal handling for stopping threads is always inefficient, when in reality it's a simple trade-off between responsiveness and performance. In any case, for better or for worse, Java multithreading is moving away from manually starting and stopping threads. – biziclop May 14 '16 at 10:34
  • @biziclop Sorry, but for aliens, it is nonsense to claim that `there is no performance penalty` and `there is a trade off between performance and responsiveness`. The two statements are inconsistent. If there is not performance penalty, as you claim, there is nothing to trade. This is what our crazy alien logic tells to us. Moreover there code maintainability penalty, that you ignore. Making code less responsive will make it more readable/managable but what is the benefit if there is no performance penalty? You can simply answer that the trade off is the only option we – Little Alien May 14 '16 at 12:21
  • have since there is no way to preeempt the obsolete thread completion, as the accepted answer did. Instead, you try to persuade me that there is no such mechanism required. `My tool is the best as it is and if you think otherwise you are wrong` is what I call a 'bigotry'. The good answer could also hing if the task schedulers that you are talking about do provide requested feature or not. Just telling 'we do not do threads anymore' is not helpful when cancellation is asked. – Little Alien May 14 '16 at 12:21
  • This isn't a forum for opinions. I've told you what the current state of affairs is, to the best of my knowledge. You can take it or leave it, I don't have an opinion on it, they're just the facts. I wish you good luck with your search for a safe, non-cooperative thread termination mechanism in Java, and if you find one, please post it here for posterity. You can also try to post a more specific question with your code, and you'll probably get a more specific answer. – biziclop May 14 '16 at 17:03

1 Answers1

1

Killing one process in an application that is composed of several interacting processes can be dangerous, but it is not usually as dangerous as killing a thread.

The ways in which one process depends on the state of another often are more limited. If the processes only interact through network communication, it probably won't be hard to design an application that can gracefully recover from having one of its processes killed. Likewise, if the processes interact through a shared transactional database.

It gets harder to handle a KILL safely if the processes interact through shared files. And it gets pretty close to impossible to guarantee the safety of an arbitrary KILL if the processes interact via shared memory.

Threads always interact via shared memory. A KILL that can't be handled, could come at any time. There's just no way to guarantee that killing some thread won't leave the whole program in a corrupt state.

That's why t.stop() is deprecated in Java. The real question should be, "why did they ever implement t.stop() in the first place?"

Solomon Slow
  • 25,130
  • 5
  • 37
  • 57