{{{
#!html
<h3 style="text-align: left; color: green">
<a href="http://gush.cs.williams.edu/trac/gush/wiki">Home</a> | 
<a href="http://gush.cs.williams.edu/trac/gush/wiki/AboutGush">About Gush</a> | 
<a href="http://gush.cs.williams.edu/trac/gush/wiki/UsingGush">Using Gush</a> |
<a href="http://gush.cs.williams.edu/trac/gush/wiki/GushExamples">Gush Examples</a> | 
<a href="http://gush.cs.williams.edu/trac/gush/wiki/GushTutorial">Gush Tutorial at GEC 11  |
<a href="http://gush.cs.williams.edu/trac/gush/wiki/GushSummerCamp">GENI Summer Camp</a>
</h3>
<hr>
}}}


= Gush Tutorial at GENI Summer Camp = 

By default, all process blocks in Gush are run in parallel.  You can change this through the use of predecessors and barriers.  

== Predecessors ==

A "predecessor" process block in Gush defines a process block that must complete before another process block can begin.  This allows us to control the ordering of processes on each host.  For example, suppose we have three process blocks in my experiment named p1, p2, and p3.  If we want them to execute in order, we need to specify that p2 has a predecessor of p1, and p3 has a predecessor of p2. This is shown in the following app spec (replace SLICENAME with your slice):

{{{
<gush>
  <project name="simplePred">
    <component name="ClusterPred">
      <rspec>
        <num_hosts>2</num_hosts>
      </rspec>
      <resources>
        <resource type="geni-pg" group="pgenigpolabbbncom_SLICENAME" />
      </resources>
    </component>
    <experiment name="simplePred">
      <execution>
        <component_block name="cb1">
          <component name="ClusterPred" />
          <process_block name="p1">
            <process name="cat">
              <path>echo</path>
              <cmdline>
                <arg>1</arg>
              </cmdline>
              <cwd />
            </process>
          </process_block>
          <process_block name="p2">
	    <predecessor name="p1"/>
            <process name="p2">
              <path>echo</path>
              <cmdline>
                <arg>2</arg>
              </cmdline>
              <cwd />
            </process>
          </process_block>
          <process_block name="p3">
	    <predecessor name="p2"/>
            <process name="p3">
              <path>echo</path>
              <cmdline>
                <arg>3</arg>
              </cmdline>
              <cwd />
            </process>
          </process_block>
        </component_block>
      </execution>
    </experiment>
  </project>
</gush>
}}}


== Barriers ==

While predecessors specify the order in which processes execute on each resource, they do not provide any guarantees about the order of process execution across resources.  If we want to enforce a more "global" ordering, we must use barriers.  A barrier block is defined in a manner similar to a process block, with the addition of a "max" attribute that indicates how many hosts must reach that point before any individual host is allowed to continue.  

In the following app spec, p1 and p2 run sequentially on each resource, then execution blocks on the barrier, and then p3 is run.  (Note: If we remove the predecessor tag in p2, p1 and p2 would run in parallel.)

{{{
<gush>
  <project name="simpleBarrier">
    <component name="ClusterBarrier">
      <rspec>
        <num_hosts>3</num_hosts>
      </rspec>
      <resources>
        <resource type="geni-pg" group="pgenigpolabbbncom_SLICENAME" />
      </resources>
    </component>
    <experiment name="simpleBarrier">
      <execution>
        <component_block name="cb1">
          <component name="ClusterBarrier" />
          <process_block name="p1">
            <process name="cat">
              <path>echo</path>
              <cmdline>
                <arg>1</arg>
              </cmdline>
              <cwd />
            </process>
          </process_block>
          <process_block name="p2">
	    <predecessor name="p1"/>
            <process name="p2">
              <path>echo</path>
              <cmdline>
                <arg>2</arg>
              </cmdline>
              <cwd />
            </process>
          </process_block>
	  <barrier_block name="Barrier Block 1">
            <predecessor name="p2"/>
            <barrier name="Barrier Block 1" type="1" max="2" />
          </barrier_block>	    
          <process_block name="p3">
	    <predecessor name="Barrier Block 1"/>
            <process name="p3">
              <path>echo</path>
              <cmdline>
                <arg>3</arg>
              </cmdline>
              <cwd />
            </process>
          </process_block>
        </component_block>
      </execution>
    </experiment>
  </project>
</gush>
}}}

Note: Barriers can even be used across components to synchronize different types of resources. Just make sure the correct barrier "name" is used in the predecessor tags.