[petsc-dev] new work on to start on threading and PETSc

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>   Jed,
>
>    Paul started today. I talked about the big picture and pointed him to the thread comm code. 

Okay, excellent.

>    What should he start with? I seem to recall you wanting to move the
>    thread initialization into PetscInitialize()? Would that be a good
>    task to get his feet wet with changing code?

I want to be able to create and relinquish threads rather than insist on
having our own thread pool.  I think it's worth reading about the design
here, as a related execution model that we would like to be able to
support.

  https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/380

Before tinkering with PetscInitialize (a hairy beast at times), we
should try to support patterns like this:

#pragma omp parallel
  {
    int trank = omp_get_thread_num();
    if (trank) {
      PetscThreadPoolJoin(pool); // thread becomes member of the pool
    } else {
      PetscThreadPoolWait(pool, omp_get_num_threads()); // make sure all threads have joined
      PetscThreadCommRunKernel(...);
      PetscThreadPoolReturn(pool); // threads waiting in PetscThreadPoolJoin return
    }
  }


The key point is that even though many PETSc objects may linger, the
user has possession of all threads after they return from joining the
pool.  Clearly this could use pthreads or another model.

I'm not sure whether a thread pool should be distinct from a thread
comm.  The tradeoff is fewer objects versus multi-purpose objects with
more conditionals.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140519/435ea44a/attachment.sig>