Agenda

• Announcements
• OpenMP

Announcements

• Homework back.
• Take a look at the TotalView debugger.
• Send information for NPACI accounts, fill out web form for NCSA accounts.

OpenMP

We started to discuss OpenMP last week.

Please read this OpenMP Tutorial from Lawrence Livermore National Labs.

The official OpenMP web site is http://www.openmp.org.

Functionally, OpenMP programming is similar to pthreads programming, but OpenMP puts some more of the burden on the compiler.

A few things to mention (or recap):

• Setting the maximum number of threads (OMP_NUM_THREADS environment variable or the omp_set_num_threads() function requests a certain number of threads. You are not guaranteed to get that many.
• When a thread reaches a #pragma omp parallel directive, it creates a team of threads and becomes the master of the team. The master is a member of that team and has thread number 0 within that team.
• Starting from the beginning of this parallel region, the code is duplicated and all threads will execute that code.
• There is an implied barrier at the end of a parallel section. Only the master thread continues execution past this point.

Last time, we looked at an example of an OpenMP matrix-matrix multiply, where we used a #pragma omp parallel for directive to let OpenMP parallelize our for loop.

We can also take more control, similar to the way we did with pthreads:

• Explicit domain decomposition:

  matmult_omp_explicit.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

  Things to note:

  The simple thread creation and destruction, calling worker()
  The worker has a bunch of local variables, all of which are private to the calling thread
  The computation of the row range for each thread, based on numthreads and threadid
• Bag of tasks:

  matmult_omp_bagoftasks.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

  Things to note:

  No worker function here - the threads are defined by the block inside the { ... } pair following the #pragma omp parallel directive.
  The shared and private clauses tell OpenMP which variables that we use inside the multithreaded block should be shared or private to each thread.
  The critical section for the concurrent access to next_avail_task is taken care of by the #pragma omp critical(mutex) directives. By naming the critical sections with the name "mutex" they are essentially the same critical section (as both deal with the same variable). The name "mutex" here is just a name - it could be anything. This replaces all the declarations, initialization, locking and unlocking, and destruction of the mutex in the pthread version.

More clauses to parallel directives

A parallel directive can take a number of clauses to define how variables are to be treated.

• private(variables): indicate that the variables in the list are to be private to each thread created.

  Any previous value is not seen by the threads, and that value is still there when the parallel block ends.

  openmp_private.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

• shared(variables): indicate that the variables in the list are to be shared among all threads created.

  Any previous value is seen by all threads, and any changes made by threads will persist when the parallel block ends.

  openmp_shared.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

• firstprivate(variables): Give the copies of the variables within each thread the initial value which is the the value the variable had outside the parallel block.
• lastprivate(variables): Take the values of the variables in the "last" thread (for a parallel for loop, or parallel sections) and store that in the variable outside the parallel block.
• reduction(op:variable): Perform a reduction on the variable and store the reduced value in the variable when the parallel block finishes.

  openmp_reduction.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

  What is a reduction? Basically, the operator is applied to combine the given variable's value in each thread, and the overall result is stored in the variable when the parallel block returns.

  We'll see many examples when we talk about message passing. Here's one that's a little more interesting than the made up example above:

  matmult_omp_explicit2.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

Other parallel directives

There are several other directives worth looking at a bit:

• sections:

  Define sections of code (that aren't a loop) that can be executed concurrently. An overly simplistic example:

  openmp_sections.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

  Each defined section is a block that can be assigned to a thread.

  This is useful when we have different tasks to assign to each thread created.

• single:

  Used within a parallel block, this specifies that the block inside the single should be executed by exactly one thread.

• master:

  This is a lot like single, but we are guaranteed that the master thread does the execution.

• critical:

  We've seen this - it defines a critical section.

• barrier:

  Used within a parallel block, this causes the threads to synchronize at this point. This could be used, for example, to make sure that the threads all complete some preliminary computation before moving on to their next step.

• atomic:

  Force a simple statement that modifies a single variable to be atomic. It is essentially a critical section, but since it is more restrictive, the compiler may choose more efficient techniques.

Yet another matrix-matrix multiply example that uses some of these:

matmult_omp_explicit3.tgz Also available in /home/faculty/terescoj/shared/cs338/lect06.

OpenMP Locks

OpenMP has lock variable type and associated functions to operate on them that work a lot like pthread mutex. Often, the critical directive can be used, but these are more general.