Skip to content

Threads WG Meeting 1 29 2019

Jump to bottom
Manjunath Gorentla Venkata edited this page Jan 29, 2019 · 2 revisions

(Thanks Thomas for the notes)

Agenda

Discussion on the tickets/issues : #257, #243

Attendees:

  • Min S. (ANL)
  • Naveen R. (Cray)
  • Swaroop P. (ORNL)
  • Thomas N. (ORNL)
  • Manjunath GV (Mellanox)
  • Anshuman G. (NVidia)
  • "wireless caller?"
  • Akhil L. (NVidia)
  • Rahman

Fortran Proposal Update (Naveen)

  • PR# 257 (fixes #249)
  • Wrapper of C for Fortran
  • Supports any compiler (Fortran 2003)
  • Interface useful for building other interoperability
  • Created separate doc for language binding extensions for oshmem (separate from main spec.), so can add other language bindings in the future
  • Fortran 2003 introduced standard way to create bind(c) interface for interoperability, wrapper interfaces over the C language interfaces
  • No semantic differences between Fortran/C mapping so just reuse existing
  • Some distinctions, the context arg can be left off (if needed) and the wrapper can cope with that to properly cope with bindings without having to add something additional/special
  • Next target is to use this for CoArray Fortran
  • Input - should cover all of oshmem before adding CoArray Fortran
  • Not including the type oriented API (e.g., shmem__put), b/c users said they did not need for Fortran
  • Tested with different compilers and not seen issues
  • Will try with oshmem
  • Has NAS benchmarks for testing, but may not part of the pull-request. For testing, Naveen will send link for that implementation after the call.

Interoperability Update (Min)

  • PR# 243
  • Status of interoperability
  • Issues proposed with shmem_initialized/finalized API
  • Challenge: when shmem already initialized by another library (testing "is intialized" is not atomic across libs)
  • Challenge: Race on init/init_thread between threads
  • Like to allow multiple init calls, to allow subsequent (extraneous calls) be "no-op" and only increase a counter
  • See end of ticket #243 for summary of issues
  • Input - how do you cope with lib1/lib2 calling init? Will have to be handed by the runtime (e.g., global flag in runtime)
  • Ordering of init/finalize
    • Case1: If shmem/mpi use unified runtime
      • RTE maintain ref counter and not release resources until last finalize
    • Case2: If shmem/mpi use indepent runtime
      • MPI standards not allow multiple inits (MPI problem, see Sessions proposal)
    • See slide #3 for more details
  • Ongoing tasks - create separate ticket for init/fini issue when using multiple shmem libs
  • Ongoing tasks - finish PDF draft of interoperability section, including
    • MPI Interoperability: Dynamic process creation , thread safety, mapping PIDs, sync/ordering, progress, etc.
    • See slide #4 for more details
  • Reviewed interleaving of init/finalize calls Options 1-4 as summarized at end of Ticket #243
  • Question - why was shmem_finalize added? For tools?
    • Response - Yes, partly tools. But also as way to unload shmem created resources (e.g., symmetric heap) when they are no longer needed, which might not be at program termination but earlier/middle of program life.
  • Input - concern over thread interleaving with init/fini, and allowing a ref-counted version of fini. (T1: init, T2:init, T2:fini, T1 uses shmem... badness?)
  • Input - delayed ref-count fini could cause problems by not actually release the resources until ref-count zero. It could also be that
  • Question - MPI dynamic process creation interactions? Was discussed on #243, see slides from 2018-sep-18 and 2018-oct-30 for Dynamic process creation discussion
Clone this wiki locally