[Swift-commit] r3296 - text/internals/trunk

[noreply at svn.ci.uchicago.edu]

Author: aespinosa
Date: 2010-04-30 10:19:39 -0500 (Fri, 30 Apr 2010)
New Revision: 3296

Modified:
   text/internals/trunk/internals.tex
Log:
First draft of notes from first meeting

Modified: text/internals/trunk/internals.tex
===================================================================
--- text/internals/trunk/internals.tex	2010-04-30 15:19:36 UTC (rev 3295)
+++ text/internals/trunk/internals.tex	2010-04-30 15:19:39 UTC (rev 3296)
@@ -1,87 +1,112 @@
 \documentclass{article}
 
+\usepackage{url}
+
 \title{Swift Internals}
 \author{
   Mihael Hategan \\
   scribe: Allan Espinosa
 }
 
+\newcommand{\filename}[1]{\textit{#1}}
+\newcommand{\snippet}[1]{\texttt{#1}}
+
 \begin{document}
 \maketitle
 \section{Provider model}
+
 Providers are asynchronous.  Internally these are implemented as lightweight
 threads.  It consumes less resources when a job is executing.  Jobs only consume
 resources when submitting a job and receiving a notification when a job
-finished.  In between, the thread is simply waiting for the job to finish.  By
-using lightweight threads, less resources are consumed.
+finished.  In between the two events, the thread is simply waiting for the job
+to finish.  By using lightweight threads, no memory is consumed in this period.
+This is the basic architecture on how providers work.
 
-not native threads.  consumes smaller resources when a job is executing. light
-weight threading (green threads: don't consume memory when nothing is running).
-This is how a provider works
+If it is desired to monitor a task, a listener such as \snippet{StatusListener}
+is added to the task.  In the example code in
+\url{http://wiki.cogkit.org/wiki/Java_CoG_Kit_Abstraction_Guide#How_to_execute_a_remote_job_execution_task},
+the \snippet{addStatusListener()} method is called in the \snippet{Task} object.
 
-{
-Submit()
-addListener()-> called when the job is done. add when you make a submit() job 
-}
-vs
-just runJob()
+A remote execution task can be summarized in a few steps: (1) create a new
+\snippet{Task} object with the corresponding execution provider using the
+constructor from \snippet{TaskImpl}, (2) add a listener to monitor the task (3)
+create a \snippet{JobSpecification} and attach this to the \snippet{Task}
+object, (4) set the \snippet{Service} specification for the remote execution
+site, and (5) create a \snippet{TaskHandler} to submit the task.  These classes
+can be found in the \filename{abstract-common} module of the CoG source tree.
 
-CPU (on submit site): fill with as much of submission and notification.
-Task
-Handler -> that can actually execute these tasks
-Handler.submit(Task) 
+\begin{verbatim}
+Task task = new TaskImpl(...);
+task.addStatusListener(public statusChanged()...);
+JobSpecification spec = new JobSpecification(...); spec.set...;
+Service serv = new Service(...);
+task.setSpecification(spec);
+task.setService(service);
+TaskHandler handler = AbstractionFactory...;
+handler.submit(task)
+\end{verbatim}
 
-in \verb1 modules/abstract-common1
-src/org/globus/cog/abstraction/impl/common/task
+The reference classes are found in
+\filename{src/org/globus/cog/abstraction/impl/common/task}.
 
-public interface TaskHandler
-public interface Task
-
-
 \section{Karajan}
 
-Stackframes. Every element (execution unit) is a function
-  - java hashtables
+Every element (execution unit) is a function and has its own stackframe.  The
+stackframe are currently implemented as java hashtables.
 
-procedure invocations gets these 
+Procedure invocations gets these internal functions: \snippet{start()},
+\snippet{waitDone()}.  All of these are executed asynchronously.
 
-start()
-waitDone();
+\begin{verbatim}
+sequential(
+   job1
+   job2
+)
+\end{verbatim}
+job2 will only be executed when job1 triggers the \snippet{Done} event. It can
+be logically viewed as 
 
-everything is asynchronous.
-
-sequential:(
-     job1,
-     job2)
-   job1.start()
-    job1.done() {
-          job2.start()
-        }
-   job2.done() {
-          "i'm done"
-   }
+\begin{verbatim}
+job1.start()
+job1.done() {
+  job2.start()
+}
+job2.done() {
+  "i'm done"
+}
+\end{verbatim}
 parallel: (decrements until 0 => done)
 
 That
   Thread1
   Thread2
 
-a parenthesis creates a local scope (1 stack frame)
+A parenthesis creates a local scope (1 stack frame)
 
-Threads creates a new scopes
+Threads creates a new scope
 
-partial arguments
-for(i in range(0,10), (do something) )
+An element features partial arguments:
+\snippet{for(i in range(0,10), (do something) )}
 
 \section{Swift karajan}
+
+The \filename{bin/swift} program can execute pre-compiled karajan .k files.
+
+Basic components used by swift:
+
+\begin{verbatim}
 import("sys.k")
 wait()
 delay()
 sequential()
 parallel()
+\end{verbatim}
 
 \section{Futures}
 
+Used by swift variables to wait for availability of data sources.
+
+\begin{verbatim}
 a := future(wait(delay=2000), "A")
 
 [a,b] := seq(1,2)
@@ -99,9 +124,11 @@
   wait(delay=1000)
   wait(delay=2000)
 ) -> slightly parallel
+\end{verbatim}
 
 \section{Channels}
 
+\begin{verbatim}
 import("sys.k")
 
 c := futureChannel(
@@ -109,16 +136,21 @@
     wait(delay=1000), i
   )
 )
+\end{verbatim}
 
-not this: [ future(wait(1000), 0), future(2), future(3)... future(9) ]
-but this: [], [0], [0, 1], [0, 2]
+Channels are not implemented as an array of futures \snippet{[
+future(wait(1000), 0), future(2), future(3)... future(9) ]}.  But as an array
+whose content changes over time \snippet{[], [0], [0, 1], [0, 2]}
 
 for(j, c, echo(j))
 
 basic concurency book
 
-how swift works:
-Alg 1 (channels)
+\subsection{Core swift}
+
+Basic karajan structure of a compiled swiftscript
+
+\begin{verbatim}
 c := channel()
 parallel(
   sequential(
@@ -129,12 +161,17 @@
     echo(first(c))
   )
 )
+\end{verbatim}
 
 equivalent swift code:
+\begin{verbatim}
 c = generate();
 consume(c);
+\end{verbatim}
 
 Used for swift arrays
+
+\begin{verbatim}
 import("sys.k")
 
 c := futureChannel(
@@ -143,6 +180,7 @@
     list(i, chr(i))
   )
 )
+\end{verbatim}
 
 
 \end{document}