Page History

...

class Helper {
  public void handle(String request) {
    //... 		
  }	
}

class GetRequest {
  protected final Helper h = new Helper();
  String request;

  public synchronized String accept() {
    String data = "Read data from pipe";
    // Read the request data, else block
    return data;
  }

  public void requesthandleRequest() {
    while(true) {
      request = accept();
      new Thread(new Runnable() {
        public void run() {
          h.handle(request);
        }
      }).start();
    }
  }
}

...

This compliant solution uses a _Fixed Thread Pool_ that places an upper bound on the number of simultaneously executing threads. Tasks submitted to the pool are stored in an internal queue. This prevents the system from getting overwhelmed when trying to respond to all incoming requests and allows it to degrade gracefully by serving a fixed number of clients at a particular time. \[[Tutorials 08|AA. Java References#Tutorials 08]\]

According to the Java API \[[API 06|AA. Java References#API 06]\] documentation for the {{Executor}} interface:

Wiki Markup
\[The Interface {{Executor}} is\] An object that executes submitted {{Runnable}} tasks. This interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. An {{Executor}} is normally used instead of explicitly creating threads.

class GetRequest {
  final Helper h = new Helper();
  String request;
  final int NoOfThreads = 200; // Maximum number of threads allowed in pool
  final Executor exec;
 
  GetRequest() {
    exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);	  
  }

class GetRequest {
  protected final Helper h = new Helper();
  String request;

  public synchronized String accept() {
    String data = "Read data from pipe";
    // Read the request data, else block
    return data;
  }

  public void requesthandleRequest() {
    int NoOfThreads = 200;
    Executor exec = (Executor) Executors.newFixedThreadPool(NoOfThreads);
    while(true) {
      request = accept();
      exec.execute(new Runnable() {
        public void run() {
          h.handle(request);
        }
      });
    }
  }
}

According to the Java API \[[API 06|AA. Java References#API 06]\] documentation for the {{Executor}} interface:

Wiki Markup
\[The Interface {{Executor}} is\] An object that executes submitted {{Runnable}} tasks. This interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc. An {{Executor}} is normally used instead of explicitly creating threads.

Noncompliant Code Example

In reality, there There are some problems associated with the incorrect use of the Executor interface. For one, tasks that depend on other tasks should not execute in the same Thread Poolthread pool. A task that submits another task to a single threaded Executor remains blocked until the results are received whereas the second task waits until may have dependencies on the first one has concludedtask. This constitutes a deadlock.

This noncompliant code example shows a _thread starvation deadlock_. This situation not only occurs in single threaded Executors, but also in those with large Thread Pools. This can happen when all the threads executing in the pool are blocked on tasks that are waiting on the queue. A blocking operation within a subtask can also lead to unbounded queue growth. \[[Goetz 06|AA. Java References#Goetz 06]\] 

// Field password is defined in class InitialHandshake
class NetworkServer extends InitialHandshake implements Runnable {
  private final ServerSocket serverSocket;
  private final ExecutorService pool;

  public NetworkServer(int port, int poolSize) throws IOException {
    serverSocket = new ServerSocket(port);
    pool = Executors.newFixedThreadPool(poolSize);
  }
 
  public void run() {
    try { 
      // Interdependent tasks
      pool.submit(new SanitizeInput(password));  // Passwordpassword is defined in class InitialHandshake 
      pool.submit(new CustomHandshake(password));  // for e.g. client puzzles 
      pool.execute(new Handle(serverSocket.accept()));  // Handle connection
    } catch (IOException ex) { 
      pool.shutdown();
    }	 
  }
}

Compliant Solution

Always try to submit independent tasks to the Executor. Choosing a large pool size can also help reduce thread starvation problems. Note that any operation that has further constraints, such as the total number of database connections or total ResultSets open at a particular time, impose an upper bound on the Thread Pool size as each thread continues to block until the resource becomes available. The other rules of fair concurrency, such as not running response sensitive tasks, also apply.

Sometimes, a {{private static}} {{ThreadLocal}} variable is used per thread to maintain local state. With Thread Pools, these should be employed only if their lifetime is shorter than that of the corresponding task \[[Goetz 06|AA. Java References#Goetz 06]\]. Moreover, such variables should not be used as a communication mechanism between tasks. Finally, the choice of the unbounded  {{newFixedThreadPool}} may not always be the best. Refer to the API documentation for choosing between the former, {{newCachedThreadPool}}, {{newSingleThreadExecutor}} and {{newScheduledThreadPool}} to suit the design requirements.

In this noncompliant code example, the SanitizeInput task depends upon the CustomHandshake task for the value of password whereas the latter depends on the former to return a password that has been correctly sanitized.

Compliant Solution

This compliant solution recommends executing the interdependent tasks as a single task within the Executor. In other cases, where the subtasks do not require concurrency safeguards, the subtasks can be moved outside the threaded region that is going required to be executed by the Executor.

class NetworkServer extends InitialHandshake implements Runnable {
  private final ServerSocket serverSocket;
  private final ExecutorService pool;

  public NetworkServer(int port, int poolSize) throws IOException {
    serverSocket = new ServerSocket(port);
    pool = Executors.newFixedThreadPool(poolSize);
  }
 
  public void run() {
    try {
      // Execute interdependent subtasks as a single combined task within this block
      // Tasks SanitizeInput() and CustomHandshake() are performed together in Handle()
      pool.execute(new Handle(serverSocket.accept())); // Handle connection
    } catch (IOException ex) { 
      pool.shutdown();
    }	 
  }
}

Always try to submit independent tasks to the Executor. Thread starvation issues can be mitigated by choosing a large pool size. Note that operations that have further constraints, such as the total number of database connections or total ResultSets open at a particular time, impose an upper bound on the thread pool size as each thread continues to block until the resource becomes available. The other rules of fair concurrency, such as not running time consuming tasks, also apply. When this is not possible, obtaining real time result guarantees from the execution of tasks is usually an unattainable target.

Sometimes, a {{private static}} {{ThreadLocal}} variable is used per thread to maintain local state. When using thread pools, {{ThreadLocal}} variable should be used only if their lifetime is shorter than that of the corresponding task \[[Goetz 06|AA. Java References#Goetz 06]\]. Moreover, such variables should not be used as a communication mechanism between tasks. 

Finally, the choice of the unbounded newFixedThreadPool may not always be the best. Refer to the API documentation for choosing between newFixedThreadPool, newCachedThreadPool, newSingleThreadExecutor and newScheduledThreadPool to meet the design requirements.

Risk Assessment

Using simplistic concurrency primitives (often incorrectly too) may lead to to process an unbounded number of requests may result in severe performance degradation, deadlocks and starvation, or exhaustion of system resources . This results in a (denial-of-service attack).

...