title: OpenMP schedule(static) with no chunk size specified: chunk size and order of assignment
body: <p>I have a few questions regarding <code>#pragma omp for schedule(static)</code> where the chunk size is not specified.  </p>
  
  <p>One way to parallelize a loop in OpenMP is to do it manually like this:</p>
  
  <pre><code>#pragma omp parallel 
  {
      const int nthreads = omp_get_num_threads();
      const int ithread = omp_get_thread_num();
      const int start = ithread*N/nthreads;
      const int finish = (ithread+1)*N/nthreads;
      for(int i = start; i&lt;finish; i++) {
          //          
      }
  }
  </code></pre>
  
  <p><strong>Is there a good reason not to do manually parallelize a loop like this in OpenMP?</strong>  If I compare the values with <code>#pragma omp for schedule(static)</code> I see that the chunk sizes for a given thread don't always agree so OpenMP (in GCC) is implementing the chuck sizes different than as defined in <code>start</code> and <code>finish</code>.  Why is this?</p>
  
  <p>The <code>start</code> and <code>finish</code> values I defined have several convenient properties.</p>
  
  <ol>
  <li>Each thread gets at most one chunk.</li>
  <li>The range of values for iterations increase directly with thread number (i.e. for 100 threads with two threads the first thread will
  process iterations 1-50 and the second thread 51-100 and not the other way around).</li>
  <li>For two for loops over exactly the same range each thread will run over exactly the same iterations.</li>
  </ol>
  
  <p><strong><em>Edit:</strong> Original I said exactly one chunk but after thinking about it it's possible for the size of the chunk to be zero if the number of threads is much larger than <code>N</code> (<code>ithread*N/nthreads = (ithread*1)*N/nthreads</code>).  The property I really want is at most one chunk.</em></p>
  
  <p><strong>Are all these properties guaranteed when using <code>#pragma omp for schedule(static)</code>?</strong> </p>
  
  <p>According to the OpenMP specifications:</p>
  
  <blockquote>
    <p>Programs that depend on which thread executes a particular iteration under any other circumstances are non-conforming.</p>
  </blockquote>
  
  <p>and</p>
  
  <blockquote>
    <p>Different loop regions with the same schedule and iteration count, even if they occur in the same parallel region, can distribute ite rations among threads differently. The only exception is for the <em>static</em> schedule</p>
  </blockquote>
  
  <p>For <code>schedule(static)</code> the specification says: </p>
  
  <blockquote>
    <p>chunks are assigned to the threads in the team in a round-robin fashion in the order of the thread number.</p>
  </blockquote>
  
  <p>Additionally the specification says for `schedule(static):</p>
  
  <blockquote>
    <p>When no chunk_size is specified, the iteration space is divided into chunks that are approximately equal in size, and at most one chunk is distributed to each thread.</p>
  </blockquote>
  
  <p>Finally, the specification says for <code>schedule(static)</code>:</p>
  
  <blockquote>
    <p>A compliant implementation of the static schedule must ensure that the
    same assignment of logical iteration numbers to threads will be used in two
    loop regions if the following conditions are satisfied: 1) both loop regions have the same number of loop iterations, 2) both loop regions have the same value of chunk_size specified, or both loop regions have no chunk_size specified, 3) both loop regions bind to the same parallel region.</p>
  </blockquote>
  
  <p>So if I read this correctly <code>schedule(static)</code> will have the same convenient properties I listed as <code>start</code> and <code>finish</code>  even though my code relies on thread executes a particular iteration.  <strong>Do I interpret this correctly?</strong>  This seems to be a special case for <code>schedule(static)</code> when the chunk size is not specified.</p>
  
  <p>It's easier to just define <code>start</code> and <code>finish</code> like I did then try and interrupt the specification for this case.</p>