Threads WG Meeting 05 15 2018

* Merged Handles
    * Took a step back, separated the merge requests semantics out of the 
      proposal
    * There is an updated ticket/proposal on PR #103 
    * Provided a reading....
        a. Merged handle was removed from the ticket
        b. Have use case with SSCA1, but the community feels that is not 
           enough for merged requests
        c. No contexts in these interfaces
            i. Not sure yet how to deal with contexts on that context
            ii. Need to make a case as to why we need contexts. We do not 
                currently have one, but we will have an answer when we 
                bring it to the reading.
        d. Were there any examples? If not, do you think they'd be valuable
            i. None right now, we can add some 
            ii. Would be curious what a pipeline example would look like
            iii. Basic usage patterns, maybe similar to the  
                 context handles
        e. Another goal of requests: that the implementation could utilize
           different transmission resources if you had two different 
           requests. 
            i. At the interface-level, we do not have this, but we could 
               with a simple info object. 
            ii. more information, more implementation
        f. Would it be better to just have the user make use of the contexts
           interfaces instead? 
        g. Mentioned performance question prior about merged request vs. 
           contexts?
            i. We showed this last year, should get all the performance 
               you could get with contexts
        h. Thread handles are not thread-safe? Can multiple threads work on
           the same thread handle concurrently
            i. Not sure, we'll get back to you on it
            ii. Reason I said yes, the request object that is created is 
                mostly read-only. so why would this be not thread-safe.
            iii. Can only perform one operation per request without a wait
* Threaded collectives
    * Swaroop will send out slides from last meeting
    * There will be a use case to drive this
    * Looking at applications or patterns for collectives
        a. Not many possible threaded users since thread model was just 
           introduced
        b. Just a toy example with the collective
* Locks/threads/domains
    * Announcement: wrote up proposal to the SHMEM_LOCK API, will read at
      the next meeting
    * Domains: in 1.4 we decided they'd be automatic, and wanted to revisit
      to see if users wanted to have more direct control. we do not have 
      a proposal draft written yet. 
        i. Need a driver to indicite if impactful, won't have this until 
           more user experience with the context interface
            a. Should we wait until we have the user experience?
            b. Should we develop in parallel to see what users are doing 
               with the 1.4 API
                1) OK with developing in parallel, but teams should be 
                   the priority in the near term.
        ii. Maybe push to next spec...
        iii. We should be able to test the benchmarks we have so far to 
             see if there's value in it
        iv. Push to next spec (1.6)

(Thanks Ferrol for the meeting minutes)