Lecture Notes for Concurrent Programming

29 July 2003 - Asynchronous Request-Response

Outline

• Asynchronous Request-Response

  • Callbacks

  • Fork-Join Synchronization

  • Futures

  • Callables

• Managing Pending Requests

Asynchronous Request-Response

• Waiting for a response can be wasteful.
  

  • The thread could be doing something besides waiting.

• Asynchronous request-response can eliminate the waiting.
  

• How do you implement asynchronous request-response?

  • In particular, what kind of synchronization is best?

Callbacks

• The server can notify the client via a callback interface.

  interface ReplyCallback
    void requestCompleted(...)
    void requestFailed(...)
  
  interface Server
    void request(..., ReplyCallback notify, ...)
  

• The client implements a callback, passing instances to the server.

• The server calls the appropriate callback routine when done.

• The client periodically checks the callback instance.

Callback Example

class ClientCallback implements ReplyCallback

  volatile boolean done = false, succeeded = true

  void requestCompleted(...)
    done = true

  void requestFailed(...)
    done = true ; succeeded = false


class Client implements Runnable

  void run() 
    MyCallback mcb = new MyCallback()
    server.request(..., mcb)

    while (!mcb.done)
      do some work

    if mcb.succeeded


class Server implements Server

  void request(..., ReplyCallback rcb)
    do the request
    if success
      rcb.requestCompleted
    else
      rcb.requestFailed

Callback Refinements

• Passing a null ReplyCallback instance indicates no reply needed.

• A client can issue multiple requests.

  • This requires multiple ReplyCallback instances.

  • Or a single instance with synchronization and identification.

• Waiting can be delegated to yet another thread by passing the callback instance.

Fork-Join Synchronization

• A thread that creates its own servers can wait for them to end.
  

• The t.join() call blocks the caller until t.isAlive() is false.

  • No return value is passed back to the joiner.

• This works better for large-grained concurrency.

  • The task work needs to cover the create-join costs.

• Parameters get passed via the forked Thread's Runnable.

  • Results can be returned the same way.

Futures

• A future is a promise to return an eventual value.

• A server can immediately reply to a request with a future.

• When the client accesses the value in a future, it blocks.

  • Or not, if the value's already in the future.

• When the server is done, it loads the future, unblocking the client
  

• Futures are like callbacks, except they scale better, and are simpler.

Implementing Futures

• For all their usefulness, futures have a simple implementation.

class Future

  private sema valueReady(0)
  private Object value

  void putValue(Object o)
    value = o
    valueReady.signal()

  Object getValue(Object o)
    valueReady.wait()
    return value

Callables

• A callable adds a future to a Runnable.

  • Futures become part of the server interface.

  class FutureResult
  
    private final future results
  
    object get()
      return results.getValue()
  
    Runnable setter(Runnable function)
      return new Runnable()
        result.put(function.run())
  

• This code should propagate interrupts too.

Managing Pending Requests

• Asynchronous request-response may pile up requests at a server.

• As requests accumulate, the server may be able to optimize performance.

  • Re-order the requests for more efficient responses.

    • Disk-arm scheduling, for example.

  • Piggy-back one reply on several requests.

• This gets to be even more fun when you throw in timers.

Points to Remember

• Don't just stand there, do something.

  • Overlapping request processing with other processing.

• Results can be returned by the requestor's callback function.

  • The control structure can get tricky.

• Requestors can fork-join synchronize with repliers.

  • Thread create and delete should be cheap.

• A future is a promise to deliver a value.

  • There should be futures in your future.

• Callables combine futures and Runnables.

  • The fewer moving parts, the better.

• Managing pending requests to improve performance.

This page last modified on 29 July 2003.