Library for signalling put and point-to-point synchronization (upc_sem_t)

[Former user]

Originally reported on Google Code with ID 80 ``` There has been intermittent discussion for years that we should add a library to support the programming practice of a "signalling put", ie a memput-like operation that transfers data and also notifies a remote thread when data has arrived. There are many potential application usages, and many opportunities for implementation-level optimizations when this usage pattern is directly expressed as a library call, rather than hand-rolled at UPC-level using strict operations.

Closely related is the idea of encapsulating point-to-point synchronization analoguous to pthread semaphores in a UPC-level library, to provide this common need in a neat package with a minimum of pointy edges.

Berkeley has a strawman specification and prototype implementation which can serve as a starting point for discussions:

http://upc.lbl.gov/publications/upc_sem.pdf ```

Reported by `danbonachea` on 2012-08-04 18:54:04

[Former user]

``` Is this proposal sufficiently well-defined to be a candidate for inclusion in the 1.3 specification?

Is there general vendor support for its inclusion?

I think that signalling puts provide useful communication pattern optimizations and are easily understood. Also, they may address some specific concerns raised in the discussion of async. mem. ops. (issue #41 - http://code.google.com/p/upc-specification/issues/detail?id=41).

```

Reported by `gary.funck` on 2012-08-13 15:54:45

[Former user]

``` "Is this proposal sufficiently well-defined to be a candidate for inclusion in the 1.3 specification?"

The proposal itself needs to be dusted off a bit, as the wording is currently rather loose and glosses over some important information. I'll work on cleaning it up and distribute a document with more concrete wording in the next few days. (So you may want to wait for that version if you haven't read it yet). ```

Reported by `danbonachea` on 2012-08-13 18:42:18

[Former user]

``` Attached is a cleaned-up version of the upc_sem_t proposal. There are a number of outstanding issues and possible extensions noted in the Appendix, so this should be viewed as a starting point for discussion.

A prototype implementation has been publicly available in BUPC since 2005. The prototype leverages the semantic flexibility of the interface to reduce all upc_memput_signal operations to a single, non-blocking one-way network message that transfers data and performs the synchronization. For large transfers this is accomplished using a zero-copy (RDMA-style) active message. For small payloads (on platforms with fast RMA support) this is accomplished using a single RMA put into a hidden bounce buffer, which is copied to the final destination by the target during the subsequent sem_wait (this optimization leverages the SPRODUCER/SCONSUMER setting and deliberately loose memory model guarantees).

```

Reported by `danbonachea` on 2012-08-15 23:56:30

<hr>

• *Attachment: [upc_sem_0.2.pdf](https://storage.googleapis.com/google-code-attachments/upc-specification/issue-80/comment-3/upc_sem_0.2.pdf)*

[Former user]

``` Here is a presentation from PGAS 2006 that introduces the upc_sem_t interface, and demonstrates its performance benefits through microbenchmarks and application examples:

http://upc.lbl.gov/publications/PGAS06-p2p.pdf

```

Reported by `danbonachea` on 2012-08-16 00:04:41

[Former user]

``` All "brand new" library proposals are targeted for starting in the "Optional" library document. Promotion to the "Required" document comes later after at least 6 months residence in the ratified Optional document, and other conditions described in the Appendix A spec process. ```

Reported by `danbonachea` on 2012-08-17 17:53:59 - Labels added: Type-Lib-Opt - Labels removed: Type-Enhancement