Do not specify UPC support for UPC threads implemented as OS threads

Issue #23 duplicate
Former user created an issue

Originally reported on Google Code with ID 23 ``` This proposal is responsive to language issues 12 and 14.

12. Are the pthreads−based implementations of UPC truly C99/POSIX/UPC conformant? Can/should the language specification speak to this?

14. Shall Berkeley’s "#pragma upc upc_code" and "#pragma upc c_code", "#pragma upc detect_upc suspend_insertion" and "#pragma upc detect_upc resume_insertion" be defined in the specification? Note that these are mainly used to deal with the difficulties of the pthreads implementation.

As described in informative issue #22, implementations that map UPC threads into OS supported threads (pthreads) implement non-compliant extensions to UPC, because they do not accurately preserve the semantics of separately compiled C libraries (for example) that make use of file scoped static variables.

This proposal recommends that the pragmas that have been vendor-defined to support the implementation of UPC threads as OS threads should not be included in the UPC specification. ```

Reported by `gary.funck` on 2012-05-21 22:02:34

Comments (3)

  1. Former user Account Deleted

    ``` I agree w/ Gary on issue #14: "This proposal recommends that the pragmas that have been vendor-defined to support the implementation of UPC threads as OS threads should not be included in the UPC specification."

    I believe that as currently implemented in Berkeley UPC the UPC-threads-as-OS-threads is marginally less than compliant (in other words, in most cases need you'll never know the difference). The pragmas mentioned in issue #14 exist to allow the user's code to work-around the areas of non-compliance.

    Despite impinging on the "#prgama upc" namespace, the Berkeley UPC team has never advocated codifying these pragmas in the UPC spec. ```

    Reported by `phhargrove@lbl.gov` on 2012-05-21 23:50:04

  2. Former user Account Deleted

    ``` This ticket looks like an near duplicate of ticket 22, or at least close enough that discussion should continue in the same place.

    Closing it pending explanation of why there is a separate issue here. ```

    Reported by `danbonachea` on 2012-05-31 08:10:44 - Status changed: `Duplicate` - Merged into: #22

  3. Former user Account Deleted

    Reported by `gary.funck` on 2012-07-06 21:04:02 - Labels added: Milestone-Spec-1.3

  4. Log in to comment