Threads WG Meeting 03 06 2018

Agenda

• Locks and Threads
• Domains

Attendees:

• Dave Ozog
• Jim Dinan
• Matias Cabral
• Michael Raymond
• Swaroop Pophale
• Wasi
• Ferrol Aderholdt
• James Ross
• Bryant Lam

SHMEM lock API

• Goal: want to more clearly define this for 1.5
  • Three github issues for shmem lock API issues

    • 174: Memory fencing text is missing

    • 193: Clear lock completes communication issued during critical section a) Two possible solutions:

      1. Require quite on default context
      2. Warn user that they should quiet the context b) Suggested solution: Perform an unlock, quiets the default context, then the user is responsible for quieting the non-default context used in the critical section o from Michael (HPE): undefined behavior if user does not quite the context

    • 205: Threaded calling of shmem_lock is undefined, difficult to implement the solutions

      a) could have application-level lock b) could have middleware-level lock

      1. space limitations if we have global queue for locks
      2. SOS implements MCS Lock implementation - essentially not enough space for global PE/thread locking queue 3. Hierarchical lock implementation - implementation provides local mutexes that allow only a single thread into the SHMEM_LOCK queue - does not provide global FCFS

Domains

• Current API, automatic domain management by implementation
  • Do we want to provide a manual API for the user to allow them to manage the resource?
    • Essentially the domain can encapsulate multiple contexts into a particular domain, which can be separate per thread.
    • May be good for next time to have more complicated examples and maybe have examples using teams?