P. 1
Wiley.pattern.oriented.software.architecture.volume.4.May.2007

Wiley.pattern.oriented.software.architecture.volume.4.May.2007

|Views: 170|Likes:
Published by Arun Nair

More info:

Published by: Arun Nair on Jun 09, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/24/2015

pdf

text

original

At the heart of HALF-SYNC/HALF-ASYNC (359) is a RequestQueue queue-
ing layer. In our CCM-based ORB, the ConnectionHandlers in
the asynchronous (reactive) layer are ‘producers’ that insert client
requests into the RequestQueue. The pool of RequestHandlers in
the synchronous (multi-threaded) layer are ‘consumers’ that remove
and process client requests from the queue.

A naive implementation of a RequestQueue can cause several prob-
lems:

• Multiple producer and consumer ORB threads in the differ-
ent layers of the HALF-SYNC/HALF-ASYNC pattern can corrupt the
RequestQueue’s internal state if concurrent access is not serialized
to protect against race conditions.

• If a simple mutual exclusion (mutex) lock is used, the producer and
consumer threads can ‘busy wait’ when the queue is empty or full,
which wastes CPU cycles unnecessarily.

How can the RequestQueue avoid race conditions or busy waiting
when threads in different layers put and get client requests simultane-
ously?

Implementing a Synchronized Request Queue

115

Implement the RequestQueue as a MONITOR OBJECT (368) to serialize
concurrent method calls, so that only one method runs at a time, and
allow its put request and get request methods to schedule their
execution sequences cooperatively, to prevent producer and consumer
threads from busy waiting when the RequestQueue is full or empty
respectively.

The synchronized RequestQueue uses a monitor lock to serial-
ize access to the monitor object, and condition variables from
POSIX Pthreads or java.util.concurrent.locks to implement the
queue’s not-empty and not-full monitor conditions. This synchro-
nized RequestQueue can be integrated into the HALF-SYNC/HALF-ASYNC
implementation in the ORB as shown in the following figure.

:Connection
Handler

handle_event

put_request

:Connection
Handler

put_request put_request

:Connection
Handler

Server-side ORB Core

«create» «activate»

:Acceptor

handle_event

ORB Core
Layer

Component Server Application

Container and
Object Adapter
Layer

run_event_loop

upcall

Container and
POA

get_request get_request

get_request

upcall

upcall

:Monitor

:not
empty

:Request
Queue

Lock

:not
full

:Request
Handler

:Request
Handler

:Request
Handler

:Reactor

116

Communication Middleware

When a consumer thread running in the pool of RequestHandlers
attempts to get a client request from an empty RequestQueue, the
queue’s get request method atomically releases the monitor lock
and the thread suspends itself on the not-empty monitor condition.
It remains suspended until the RequestQueue is no longer empty,
which happens when a ConnectionHandler running in the producer
thread puts a client request into the queue.

MONITOR OBJECT simplifies our ORB’s HALF-SYNC/HALF-ASYNC concur-
rency design by providing a concise programming model for sharing
the RequestQueue among cooperating threads in which object syn-
chronization corresponds to method invocation. The synchronized
put request and get request methods use the RequestQueue’s
monitor conditions to determine the circumstances under which they
should suspend or resume their execution.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->