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?
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?"
Related
Sometimes the system process of a java application doesn't fully shutdown. This is mainly because one or more threads didn't die.
One can call:
System.exit(0);
But this kills all threads.
I want all my threads to shutdown correctly so i don't plan on using System.exit. But sometimes due to circumstances one or more threads don't die correctly. This causes the application to not fully shutdown and linger in the background sometimes even locking up resources.
My first thought was writing an ExitWatcher which starts when program stops and calls system.exit after 10 seconds if the program is still alive. I quickly found out that the ExitWatcher now prevents the program from shutting down ;-)
How do you give a java program time to shutdown correctly (ie close all threads correctly) but at the same time have a backup plan that calls System.exit if shutdown takes too long?
You can use daemon threads when you don't want a thread to prevent a program from exiting (so using setDaemon(true) on your ExitWatcher thread would solve your immediate problem). However I doubt you really need or want an ExitWatcher, as situations like that are usually relatively easily prevented with proper design.
Proper shutdown procedures include interrupting threads that are active (and designing them so they behave nicely when interrupted), using daemon threads where necessary, shutting down connections properly etc. Using a mechanism like your ExitWatcher is more of a hackish approach, as it indicates your program doesn't always behave nicely at shutdown.
I have several threads in my Android application that should be executed concurrently. I am not running them on several cores. REAL parallel execution at exactly the same time is not necessary. If Android switches between the different tasks or temporarily pauses certain threads, it's Ok.
The problem: Some threads are highly time consuming and computationally expensive (complex algorithms), but are not real time critical. Other threads and the Android UI thread are real time critical and should not be blocked or heavily delayed by the time consuming processes. Nevertheless, the time consuming processes should also be executed if there are no other more important tasks to perform. Ideally, the highly important threads should safely pause the less important threads. In Java people used to implement suspend() commands, but they are now depricated.
What is the recommended way to solve this problem in Android?? In Java I would have used Sleep commands or wait and notify methods. What is recommended way in Android?
Thanks for the anwer, guys!
Edit:
I was thinking about threads. But I wrote "processes" instead of "threads", just in case regular threads are not the best way to solve the problem in Android. I am open to anything. I have only ONE App. Sorry if terms get mixed up a little. But I wanted to keep the options and ideas open.
Thanks for the comments and answers so far. But I am more interested in a GENERAL, recommended, established strategy and good practice to solve this kind of problem in Android. I could also do some hacks, but I was really hoping for a clean and established solution. I am more looking for an answer like: "The common, established approach is to use strategy A + strategy B..."
In my opinion you should use a different component (Service) and set it to run on a different process - here you can see how
By doing so you can put all the computing in a different process that not related to your man UI component lifecycle.
If the dependency of algorithms' logics and the main UI is loose I wouldn't try to implement them via Threads concurrency.
Does anybody know a mechanism that can capture the state of a running thread and serialize that for further resume?
Is there anything available for the JVM?
How about pthreads?
My main goal is to be able to migrate a running thread to a remote machine.
With the cooperation of that thread, you can do it by any mechanism that thread supports. Without the cooperation of that thread, it is impossible. What happens if that thread holds a lock that your serialize code needs?
What happens if you migrate a running thread that is currently using some kernel resource such as a pipe. Will you migrate that resource?
The right solution to your problem may be to have the thread support a migration mechanism. How you do that depends on precisely what that thread is doing. You'll get answers that are more likely to help you solve your actual problem if you explain precisely what is.
The answer to this is really going to depend on what constitutes the state of the running thread.
If the state is local thread data which allows for the thread state to be copied and saved and then inserted back into a new thread, then the mechanism is basically to just save the state with some kind of a serializable object which is then used to create a new thread with the saved state and to then begin it running.
However if the thread state depends on external objects or entities, the problem is much tougher. For instance if you have a thread which is acting as a server using TCP and you want to save its state then restart it later, the socket is going to change and the client which was accessing the server thread will know that the server thread stopped communicating for a while.
This means that for any external entities that are depending on the thread, will need to know that the thread is being saved and frozen, they will need to have something that allows them to either fall over to an alternative or to save and freeze themselves, and there will need to be some kind of protocol so that the restarted thread can let the other entities know that it is back in business and its current state.
Also if the thread is depending on some external entities then those entities must be able to deal with the thread being frozen. There may need to be some kind of a mechanism in place so that the thread can release various resources, whose states are saved, and then when restarted, be able to reclaim those resources or comparable resources and then reset those resources to the saved state.
If you want to move a running JVM from one machine to another, you will most likely not do it by yourself but instead use the live migration functionality of a VM manager.
The VM managers will move entire virtual machines from one physical machine to another without stopping the virtual machine or processes, but it's quite a bit higher level than serializing/deserializing a thread. Since a thread may use resources that are local to the operating system such as file systems or sockets, the whole operating system needs to follow the thread to the other physical machine.
I'm not aware of any way that you can send a thread, per se. However, you could use a pattern such as the memento pattern to save the state of your thread.
See these references before continuing so you know the terminology:
Memento pattern, oodesign.com
Memento pattern, Wikipedia
Basically, you'll have this:
Design a job (thread) that can run with any starting state, including a state from mid-execution.
When it needs migrated, get the state of that thread.
In Java, you could use ThreadLocal variables to store the thread state.
Serialize that state to the other machine.
Use the state to start a new thread with the state you deserialized.
This is a better approach then actually migrating a thread, its state, stack, etc. since you can pick and choose what absolutely needs to be moved instead of moving everything no matter what.
I'm working on a multi-user Java webapp, where it is possible for clients to use the webapp API to do potentially naughty things, by passing code which will execute on our server in a sandbox.
For example, it is possible for a client to write a tight while(true) loop that impacts the performance of other clients.
Can you guys think of ways to limit the damage caused by these sorts of behaviors to other clients' performance?
We are using Glassfish for our application server.
The halting problem show that there is no way that a computer can reliably identify code that will not terminate.
The only way to do this reliably is to execute your code in a separate JVM which you then ask the operating system to shut down when it times out. A JVM not timing out can process more tasks so you can just reuse it.
One more idea would be byte-code instrumentation. Before you load the code sent by your client, manipulate it so it adds a short sleep in every loop and for every method call (or method entry).
This avoids clients clogging a whole CPU until they are done. Of course, they still block a Thread object (which takes some memory), and the slowing down is for every client, not only the malicious ones. Maybe make the first some tries free, then scale the waiting time up with each try (and set it down again if the thread has to wait for other reasons).
Modern day app servers use Thread Pooling for better performance. The problem is that one bad apple can spoil the bunch. What you need is an app server with one thread or maybe process per request. Of course there are going to be trade offs. but the OS will handle making sure that processing time gets allocated evenly.
NOTE: After researching a little more what you need is an engine that will create another process per request. If not a user can either cripple you servlet engine by having servlets with infinite loops and then posting multiple requests. Or he could simply do a System.exit in his code and bring everybody down.
You could use a parent thread to launch each request in a separate thread as suggested already, but then monitor the CPU time used by the threads using the ThreadMXBean class. You could then have the parent thread kill any threads that are misbehaving. This is if, of course, you can establish some kind of reasonable criteria for how much CPU time a thread should or should not be using. Maybe the rule could be that a certain initial amount of time plus a certain additional amount per second of wall clock time is OK?
I would make these client request threads have lower priority than the thread responsible for monitoring them.
I read some tutorial about threads and processes, it is said that the processes be scheduled by operating system kernel, and the threads can be managed and scheduled in a user mode.
I do not understand the saying "threads can be managed and scheduled in a user mode",
for example: the producer and consumer problem? is this a example for "scheduled in a user mode"? or can anyone explain me?
Not sure what tutorial you're looking at, but there are two ways that threads can be scheduled.
The first is user-mode scheduling, which basically mean that one process, using Green threads or perhaps fibers, schedules different threads to run without involving the operating system in its decision. This can be more portable across operating systems, but usually doesn't allow you to take advantage of multiple processors.
The second is kernel scheduling, which means that the various threads are visible to the kernel and are scheduled by it, possibly simultaneously on different processors. This can make thread creation and scheduling more expensive, however.
So it doesn't really depend on the problem that you are trying to solve. User-mode just means that the scheduling of threads happens without involving the operating system. Some early Java versions used Green/user-mode threads, but I believe most now use native/kernel threads.
EDIT:
Coding Horror has a nice overview of the difference between user and kernel mode.
Get a better tutorial? The official Java tutorials are quite good, and contain a lesson on concurrency, that also defines what process and thread mean.
PS: Whether threads are managed/scheduled in user mode is an implementation detail of the Java Virtual Machine that generally need not concern the application programmer.
Scheduled in user mode means you have control over the threads of your software but they are managed by the operating system kernel. So yes, the producer consumer problem is an example you normally handle yourself (but it is not directly related to user mode scheduling) by having two threads, a producer thread and a consumer thread. Both threads access the same shared recource. This resource has to be thread-safe, this means you have to make sure the shared resource does not get corrupted becouse both threads access it at the same time. Thread safety can either be guaranteed by using thread-safe data types or by manually locking or synchronizing your resource.
However, even if you have some control over your threads e.g. starting threads, stopping threads, make threads sleep etc. you do not have full control. The operating system is still managing which threads are allowed cpu time etc.