3 Replies Latest reply on Aug 5, 2008 3:06 PM by lytles

    gfortran64_mp and threading

    lytles
      seeing crashes and deadlocks when calling gfortran_mp from multiple threads

      i'm trying to use acml in a threaded environment.

      • gfortran64  single-thread  --> success
      • gfortran64     2 threads    --> success
      • gfortran64_mp  single-thread   --> success
      • gfortran64_mp  2 threads    --> failure (crashes, deadlocks)

      i need to be able to call acml from many threads, and i'd like the lower latency of the _mp version. but it appears from my testing above that the openmp version is not thread safe. can anyone verify this ? the wrappers that i'm using are pretty simple and look thread-safe, but it's possible that the problem is mine.

      with mkl (the intel equiv to acml) i can call the openmp version from multiple threads without any problem. the wrappers are very similar.

      the release notes say:

      (o) Routines that were not safe for use by multi-threaded programs in
          some earlier releases of ACML have now been made thread safe.
          If you use ACML in a multi-threaded environment you are recommended
          not to use versions of ACML earlier than 2.1.0. (Note that this
          does not apply to the PGI-compiled SMP versions of ACML which have
          always been safe for use in OpenMP programs.)

      so i've been counting on being able to call from multiple threads. fwiw, i'm calling from java using jni, and using the java threads

       

       

       

       

       

        • gfortran64_mp and threading
          yakktr

          Hi

          I asked a similiar question, if you check it may be useful

          http://forums.amd.com/devforum/messageview.cfm?catid=217&threadid=95777&highlight_key=y&keyword1=acml

          If I didnot get it wrong gfortran_mp uses its own openmp parallel regions so you shouldnot use it in an application already multithreaded, it is safe to use _mp extensions in singlethreaded applications. 

           

          Regards

           

           

           

            • gfortran64_mp and threading
              lytles

              i had seen your post, and agree that it is very similar. but your thread confuses the issue a bit in talking about PURE and such.

              i wanted to draw attention to the very simple question, is acml gfortran64_mp thread safe ?

              my guess, your guess, and based on amd's silence, amd's understanding, is that acml gfortran64_mp is not thread safe. i don't find this acceptable - i shouldn't need to choose between throughput and safety - it makes acml_mp unusable in any library that wants to be threadable. for modern machines and environs, this is the dominant paradigm. and mkl (the intel blas/lapack) doesn't suffer from this problem.

              i consider this restriction, and amd's response (eg, to your thread) unacceptable - to claim openmp-enabled given this restriction is misleading and sloppy, a bit of a bait and switch. at the least, i'd like a list of the functions that aren't thread-safe, so that i could implement my own locks externally. but maybe that's just me

              sure wish there was a preview button, so i could see what the quoted portion would look like.

               

               

              Originally posted by: yakktr

              I asked a similiar question, if you check it may be useful

              http://forums.amd.com/devforum/messageview.cfm?catid=217&threadid=95777&highlight_key=y&keyword1=acml

              If I didnot get it wrong gfortran_mp uses its own openmp parallel regions so you shouldnot use it in an application already multithreaded, it is safe to use _mp extensions in singlethreaded applications.

                • gfortran64_mp and threading
                  lytles

                  ok, i decided to wrap acml with locks for my library. this works, but i don't have enough documentation to really do it right - for now i'm just using a single lock for all blas and lapack calls to acml

                  • anyone know the nature of the non-thread-safety ?
                  • is it per function ?
                  • or library-wide ?
                  • does it matter if i'm using the c interface or the fortran interface ?