\subsection{Language Support for Javelin}
\label{sec:language}

The Javelin system presented in the previous sections provides a low-level
layer of code distribution, communication, and process execution.  Though it
provides a very flexible layer for communication and process creation,
programming at this low-level layer can be difficult.  For this
reason, we propose to extend the HTTP server with services that enable the
efficient implementation of parallel programming paradigms and constructs.
%as well as convenience functions.

%we describe simple programming models that enable programmers to express
%many parallel programming constructs in their client applet code.  These
%programming models are realized by executing specialized servlets on
%the server.


%\subsection{Services}

%Recently developed HTTP servers can be extended in two ways, either by using
%the Common Gateway Interface \cite{cgi-draft} and spawning a new process, or
%by installing servlets \cite{Sun96c}.  Servlets are small Java programs like
%applets, but are executed at the server side and, like CGI scripts, allow for
%the dynamic creation of Web pages.  They can either be embedded into Web pages
%or invoked like CGI scripts.  Currently, servlets are supported by JavaSoft's
%Jeeves \cite{Sun96c} and W3C's Jigsaw \cite{jigsaw}.
%%However, we feel that Servlets will be supported by most HTTP servers
%%released in the near future.

%We have found the servlet approach to be a very convenient way of extending
%the functionality of HTTP servers with application-specific services.
%Actually, in our prototype implementation, we even allow the application to
%upload its own new servlets.  Unfortunately, ensuring security is not easy.
%Thus, we envision that in the final deployed system, only a fixed set of
%servlets will be provided.  One of the most interesting open research
%questions is how much resources (CPU time, memory, disk space) an individual
%user should be able to get on such servers.


%\subsection{Language Support for Javelin}

Language support for a distributed and parallel programming environment
usually involves a suite of programming tools such as libraries, compilers,
pre-processors, and stub generators.  The Javelin programming environment
provides a number of library support classes and tools to map different
programming models onto the current applet infrastructure.  To illustrate how
these language constructs can be mapped, we consider the implementation of a
Linda tuple space as an example.


%\subsection{SPMD Programming Model}

%The Single Program Multiple Data programming model is perhaps the most
%widely
%supported form of parallel programming.   Each node on a network executes
%a common copy of the same program code.  Parallelism  is obtained by
%providing different data inputs to each node, and combining their 
%computations into a common result.

%The SPMD model is easily mapped onto Javelin.  Each node on the network 
%executes a common applet, representing the single program code.  Data can
%be read in at run-time through the broker, or can be coded into the applet
%and replicated among all the hosts, each node working on its portion  of
%the data.  Synchronization mechanisms conducted through the broker is
%provided to coordinate the tasks involved.  We explore two commons forms of
%synchronization primitives:

%\subsubsection{Support for Send \& Receive}

%Message passing is  often required in a parallel program to 
%pass information between hosts and direct the flow of computation.
%Toward this end, we illustrate how we map a Send and Receive onto Javelin.

%The following steps are performed:
%\begin{itemize}
%        \item Each pair of host passes {\it send} and {\it receive}
%	 requests to the broker.
%        \item If a {\it send} arrives before the {\it receive}\/ request,
%		the broker stores the data and acknowledges the
%		{\it sending} process.  The {\it sending} process can
%		continue with its computation.  When the {\it receive}\/
%		request arrives, the broker passes the data to the 
%		{\it receiving} process, so the {\it receiving} process can
%		also continue processing.
%        \item If a {\it receive}\/ request  arrives before a {\it send}\/,
%		the broker must reply to the {\it receiving} process that
%		the {\it send} data is not yet available.  The
%		{\it receiving}
%		process, in turn, blocks and proceeds to poll the broker
%		until the corresponding {\it send} request arrives with 
%		the data.  If no {\it send} request does arrive, eventually,
%		the {\it receive}\/ request times out.
%\end{itemize}
%As indicated above, no polling is required in a send-and-receive request
%unless a {\it receive} arrives before the  {\it send}.  Such polling is an
%expensive process involving issuing repeated HTTP GET requests to contact
%the broker and check if the {\it sending} data has arrived.  

%In the mapping to Javelin, we can perform a modest optimization by keeping
%the HTTP GET connection active until the {\it send}\/ data has arrived. 
%The broker periodically sends NOOP data to the host in order to prevent the 
%GET connection from timing out. The host ignores the NOOP message until
%the intended {\it send} data finally arrives.  As a further optimization,
%we can employ socket connections between host and broker to avoid polling
%altogether, at the expense of maintaining these connections.

%\subsubsection{Support for Barriers}

%One other common form of synchronization that we must support in SPMD
%program is a barrier.  Each processor executing a barrier must wait until
%all processors have reached that point in computation;  only then can the
%processor be fully synchronized and continue with subsequent execution.
%As with send-and-receive requests, it is fairly simple to implement
%a barrier in Javelin by extending the broker with a barrier servlet.

%\begin{itemize}
%        \item Each host executes a barrier operation, by sending a
%	{\it barrier}
%	request to the broker, indicating the number of hosts, $n$,
%	participating in the barrier synchronization.  The host then polls
%	the broker waiting for the broker to acknowledge with a {\it release}
%	reply.

%	\item The first {\it barrier} request that arrives at the
%	broker indicates to the broker the number of pending {\it barrier}
%	requests, $n-1$, to expect before releasing the barrier.
%	When the broker receives subsequent  {\it barrier} requests, it 
%	decrements the number of pending requests by $1$.

%	\item  If the number of pending requests is $0$, the broker 
%	acknowledges  each host poll with a {\it release} reply;  otherwise
%	if replies with {\it no-release}.
%\end{itemize}

%Just as with send-and-receive requests, a barrier can time out if a polling
%host does not receive a {\it release} reply from the broker within an allotted
%amount of time.  We can further perform the same optimizations of keeping the
%HTTP GET connection alive when a host polls a broker, or of employing socket
%connections.


%\subsection{Example: Linda Tuple Space}

%To illustrate the flexibility of the Javelin design, we will also show
%how SPMD programming can be achieved by building upon Javelin applet
%layer a programming abstraction known as  Linda tuple space.

The Linda programming model \cite{WhLe88} was originally developed by
Gelernter and Carriero of Yale University.
%in 1988.
This Linda model provides a construct, known as tuple space, that concurrent
processes can access to insert, delete, and update data known as {\it tuples}.
Atomic operations known as {\it Out}\/, {\it Rd}\/, and {\it In}\/ provide
synchronization for these accesses.  The tuple space is viewed as a central
pool  of storage that hosts contact to share data.  Programming is vastly
simplified because each parallel program need only invoke these three
primitives to pass and update information.

Mapping the Linda tuple space onto the Javelin applet layer is fairly
straightforward.  The server can act as a tuple space manager by executing a
dedicated servlet that implements the response handler for the {\it Out}\/,
{\it Rd}\/, and {\it In}\/ operations.  When host machines running applet
programs contact the server, they then invoke a high-level Linda primitive to
exchange data and information.
%We show how the two SPMD synchronization mechanisms can be implemented
%through the tuple space.


%\subsubsection{Linda Support for Send \& Receive}

%Earlier, we saw how send-and-receive required a broker executing a dedicated
%servlet to handle synchronization requests.  Though the broker must once again
%execute a servlet to provide tuple space management facilities,
%programming a send-and-receive can be vastly simplified using
%this tuple space abstraction: The host processor
%performing a {\it send} inserts a message into the tuple space by executing
%an {\it Out}\/ command, while the {\it receiving} processor executes a
%blocking {\it In}\/.  The {\it In}\/ command deletes the message from
%tuple space and delivers  it to the {\it receiving} processor.


%\subsubsection{Linda Support for Barriers}

%To provide a barrier we extend the functionality of the tuple space to
%include a general semaphore.  When each processor reaches the barrier, it
%signals the tuple space manager to decrement the count of the semaphore by
%$1$, then queries for the semaphore's current value.  While in the barrier,
%the host processor performs a busy wait, polling the tuple space manager
%until the semaphore value reaches $0$.

%A Linda tuple space thus provides a simple programming model to implement
%message passing and shared memory abstractions.  By extending the tuple
%space with additional synchronization primitives, such as a barrier, we
%can fully realize the benefits of SPMD programming in Javelin.
