A look at the JVM and thread behavior (June 28, 1999)

Q: At the base of my questions is the JVM process and thread behavior. I understand that on most platforms, the JVM runs as a single process and any threads created “belong” to that single process. This gives rise to a few questions:

• Can multiple threads overload the main process and cause it to crash?
• Can threads be started, suspended, and otherwise managed like processes can?
• What are the trade-offs between using multiple threads and multiple processes?

A:
Two implementations that Sun offers are green threads and native threads. Green-threads Java runtimes don’t require the underlying operating systems to support threads — the runtime handles scheduling, preemption, and all other thread-related tasks all by itself. One disadvantage to this scheme is that it cannot distribute threads across several CPUs, so it doesn’t take advantage of multi-CPU computers. Native-threads Java runtimes only run on operating systems that directly support threads. The OS is free to distribute threads across CPUs, but it is also free to use whatever scheduling algorithms it wishes, taking control away from the developer.

Now, on to your specific questions:

Can multiple threads overload the main process and cause it to crash?

In practice, a program will run out of memory long before it reaches any kind of thread limit. (Just for fun, the Java Q&A experts wrote a program that did nothing but create new threads, and ran it on an UltraSparc 2 with 128 MB of RAM. After the program created 10,000 threads, we became bored and gave up.) Keep in mind that each thread takes up a small but measurable amount of system resource like memory, so threads shouldn’t be created willy-nilly.

Can threads be started, suspended, and otherwise managed like processes can?

If you want to know if you can, from your terminal, look at a list of running threads and selectively kill them, the answer is no. If you’re asking if one thread in a process can get a list of threads in the same process and selectively kill them, The answer is yes. There are four lifecycle methods in the java.lang.Thread class — start() and stop(); suspend() and resume(). The start() method is fine, but suspend() and stop() should be avoided if at all possible. Here’s a code snippet from a runnable to demonstrate why these two methods are bad:

public void run()
{
   while (true)
   {
      Socket s = acceptRequest();
      Connection c = getDatabaseConnection();
      fulfillRequest(s, c);
      reclaimResources(s, c);
   }
}

Now, what would happen if this thread were stop()ped after it had opened a socket and a JDBC connection, but before it could close them? Those resources might not be closed cleanly. Even worse, what would happen if the thread were suspend()ed while creating the JDBC connection? It would keep any locks it held until it was resume()d, which (depending on the JDBC driver) might prevent any other thread from communicating with the database! The suspend() and stop() methods are just too dangerous to use. Instead, rewrite the code as follows:

private boolean mStopRequested = false;
public void requestStop()
{
   mStopRequested = true;
}
public boolean isStopRequested()
{
   return mStopRequested;
}
public void run()
{
   while (!isStopRequested())
   {
      Socket s = acceptRequest();
      Connection c = getDatabaseConnection();
      fulfillRequest(s, c);
      reclaimResources(s, c);
    }
}

The rewritten example shows how to achieve the same result as Thread.stop() without the same possibility for mayhem. This isn’t an ideal solution — if acceptRequest() is a blocking call, this thread could stay alive for a long time after requestStop() was called.

What are the trade-offs between using multiple threads and multiple processes?

Multiple threads should be the method of choice for most new applications. Threads require fewer OS resources than do processes, and are therefore quicker to create and destroy. They can also share information much more easily than processes can. The biggest drawback to choosing multithreading is that it is harder to code correctly. Code that isn’t synchronized correctly is prone to problems like race conditions and deadlocks.

:END_B0DY

Source: www.infoworld.com