[MOAB-dev] MOAB global variables and thread

[Tim Tautges (ANL)]

As long as we understand where such a global object is used, I don't think we need to worry about this particular thing 
right now.  And, since most MPI's support outputting individual rank output to separate files, and many support 
prepending any output with rank number, I don't think we really need to worry about the garbled output either (if it's a 
problem for a particular run, then they can rerun with that option to get ungarbled output).

- tim

On 01/30/2014 10:55 AM, Wu, Danqing wrote:
> How many global variables are there inside MOAB currently?According to Tim, we want to support multi-threaded calls in
> the future, so thread safe is a concern. If several threads access the same global variable at once, it could cause
> unexpected issues.
>
> I recently changed error handler to use ErrorOutput (a simplified and specialized version of DebugOutput) to output
> error messages and stack traces (prefixed with world rank for each line), as std::cout can produce a messy output:
> cout << "Hello world! I am " << rank << " of " << size << endl;
> On 4 processors, one possible output is like this
> Hello world! I am Hello world! I am Hello world! I am 2Hello world! I am 3 of 40 of 4 of 4
> 1 of 4
>
> ErrorOutput class instance is a global variable for now. So in the future, when multiple threads use it to print out
> error messages, it will not be thread safe. It will be necessary to make it global to the program, but the specific
> value is local to the thread.
>
> PETSc has mentioned similar issues:
> /A variety of global data structures are used for profiling and error handling. These are not easily removed or modified
> to make thread-safe./
>
> PETSc has used some thread local mechanisms for its global function call stack structure:
>
> #if defined(PETSC_HAVE_PTHREADCLASSES)
>    #if defined(PETSC_PTHREAD_LOCAL)
>      PETSC_PTHREAD_LOCAL void *petscstack = 0;
>    #else
>      PetscThreadKey petscstack;
>    #endif
> #else
>    void *petscstack = 0;
> #endif
>
> // PETSC_HAVE_PTHREADCLASSES defined, and PETSC_PTHREAD_LOCAL defined
> In GCC, there is an extension that provides the __thread storage class
> On a system which supports TLS (Thread Local Storage), any global (or static) variable may be annotated with |__thread|.
> The variable is then thread local.
>
> // PETSC_HAVE_PTHREADCLASSES defined, but PETSC_PTHREAD_LOCAL NOT defined
> On a POSIX system without a thread local feature, an implementation could use pthread_getspecific() to get a pointer to
> thread specific data that was allocated for each thread, and set with pthread_setspecific()
>
> Best
> Danqing
>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
  phone (gvoice): (608) 354-1459      1500 Engineering Dr.
             fax: (608) 263-4499      Madison, WI 53706