limit allowed range of values for barrier id values

[Former user]

Originally reported on Google Code with ID 26

This proposal is responsive to issue 22.

22. GCC/UPC defines "magic" values for an indefinite barrier value, and to indicate
an exit from upc_global_exit(). Would it be possible to define these operations in
a way that the runtime can use part of the value? For example, only positive integers
for a barrier value and only values in the range 0..127 as the return value for upc_global_exit().
Obviously, GCC/UPC can be re−implemented such that these restrictions are removed,
but might it make sense to leave some part of the value range for use by the runtime?

This proposal recommends that ranges of values for both the return code to upc_global_exit()
and barrier id values be restricted in order to allow the underlying UPC runtime and
libraries to use values that are outside the range required by the UPC specification.

Proposed ranges are:

upc_global_exit return code argument: 0..127
barrier id: positive (non-zero) integers

Impact: there may be some existing applications or test programs that make use of values
outside of the proposed ranges.  These out-of-range values could be detected by the
UPC runtime library so that those use cases can be corrected.

Reported by gary.funck on 2012-05-21 22:58:54

[Former user]

``` I don't see the value to the UPC community of reserving any potion of the barrier name space for use by the implementation. Since the UPC spec gives the type of the barrier value as "int", I can expect that UPC codes would want to use the entire range. Since the implementation has the freedom to implement the barrier, it also has the freedom to implement extra bits for internal uses.

I am not touching the exit code question in this comment, because I would want to research what the C and POSIX specs say about exit() first. I don't mean to imply that one MUST follow the spec for exit(), just that I'd like to review it before forming an opinion of UPC's nearest equivalent.

```

Reported by `[e-mail]` on 2012-05-21 23:41:08

[Former user]

``` There is a potential portability issue with allowing the full range of 'int' in that int may have a differing range, depending upon the target system. For example, on an ILP64 system, 'int' has a 64-bit range.

The maximum (and minimum?) barrier id values permitted by the implementation might be a candidate for upc_limits.h.

An alternative proposal for the barrier id is to reserve a certain value for an anonymous barrier, such as -1, or 0, or INT_MIN.

The implementation of upc_global_exit() has proven problematic, and reserving the high order bit of the return code allowed GUPC's runtime to effect an out-of-band communication with the monitor process, which it used as an indication that all other processes must be terminated. Obviously, other methods of communicating a call to upc_global_exit() can be implemented (and probably are already); this method proved to be simple and reliable.

```

Reported by `gary.funck` on 2012-05-22 16:58:43

[Former user]

``` Gary wrote:

There is a potential portability issue with allowing the full range of 'int' in that int may have a differing range, depending upon the target system. For example, on an ILP64 system, 'int' has a 64-bit range.

The maximum (and minimum?) barrier id values permitted by the implementation might be a candidate for upc_limits.h.

Unless we change the spec, INT_MIN and INT_MAX currently give the min and max barrier id values.

An alternative proposal for the barrier id is to reserve a certain value for an anonymous barrier, such as -1, or 0, or INT_MIN.

Are you suggesting that "upc_barrier 0;" might become equivalent to "upc_barrier;"? Such a change could introduce silent errors into a code that is currently using the chosen special value and expecting it to detect their programming errors.

If the group wants to go this direction, then INT_MIN seems to me the least likely to collide with values used in current codes. Zero is a horrible choice IMHO.

I still haven't done my research on exit(), and will reserve judgement until I have. ```

Reported by `[e-mail]` on 2012-05-22 17:09:17

[Former user]

``` Tag as "Enhancement" with a version 1.3 milestone.

```

Reported by `gary.funck` on 2012-07-03 15:06:37 - Labels added: Type-Enhancement, Milestone-Spec-1.3 - Labels removed: Type-Defect

[Former user]

``` Set default Consensus to "Low". ```

Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

[Former user]

``` Change Status to New: Requires review. ```

Reported by `gary.funck` on 2012-08-19 23:37:41 - Status changed: `New`

[Former user]

``` I will retain ownership of this issue. ```

Reported by `gary.funck` on 2012-09-19 17:04:31

[Former user]

``` Per the 9/21 telecon, this issue will be split into two separate issues. One will address the allowed range of exit() and upc_global_exit() return codes and another will deal with the allowed range of barrier identifiers, and whether the range of barrier identifiers can be restricted such that the UPC runtime can make use of upc_barrier without running the risk of conflicting with the application's use of upc_barrier.

```

Reported by `gary.funck` on 2012-09-22 18:06:36

[Former user]

``` Change the Summary to restrict this issue to discuss the allowed range of barrier id's only.

```

Reported by `gary.funck` on 2012-09-22 23:07:40

[Former user]

Reported by `gary.funck` on 2012-09-22 23:09:14

[Former user]

``` Though I argued against this on the 2012.09.21 conf call, I want to now "relax" my objections. I still think it may be "wrong headed" to restrict the user to a smaller range solely for the sake of easing the implementation of a conforming final barrier. However, putting aside my feelings about the stated MOTIVATION, I don't actually feel that strongly that such a restriction would "do harm" to the users.

I find that a quick non-scientific survey of barrier/notify/wait calls uses only non-negative values. So, I'd propose that IF we want to pursue this then "non-negative integers" is a good range to propose. I say that not because we have any actual need to reserve roughly HALF of the range of an integer, but because it is just "cleaner" than reserving one or two values at either the positive or negative extremes of the range. The idea of reserving INT_MIN would be a good second choice in my opinion. ```

Reported by `[e-mail]` on 2012-09-26 23:09:52

[Former user]

At the 11/29 telecon, Gary agreed this issue should be Rejected.

Reported by danbonachea on 2012-11-29 20:05:06 - Status changed: Rejected