(j3.2006) (SC22WG5.5062) [ukfortran] WG5 vote on draft TSon further coarray features

[Lionel, Steve]

I wrote:
<<<
Events ? I?d like to see a note or some wording specifying what happens if more than one image is waiting for an event to be posted.
>>>
 Malcolm responded:
Cannot happen because we lobotomised events ? only the image on which the event variable resides is permitted to wait (EVENT WAIT prohibits event-variable from being coindexed).

That?s not what the current TS says. From the introduction, ?An image can use an EVENT_POST statement to notify another image that it can proceed to work on tasks that use common resources. An image can wait on events posted by other images and can query if images have posted events.?

While it?s true that EVENT_WAIT doesn?t let you specify a coindexed variable, the event-variable is itself a coarray so it is possible for other images to be waiting on the event. If this is not possible, the whole idea of events makes no sense at all, since how can an image wait on itself?

It?s certainly possible that I am missing some bigger issue here.

<<<
7.4.1 (ATOMIC_ADD) ? change ?ATOM becomes defined with the value of ATOM + VALUE.? To ?ATOM becomes defined with the value of ATOM + INT(VALUE,ATOMIC_INT_KIND).?   Or is the intent that the normal mixed-mode arithmetic and assignment rules apply? This seems rather ugly to me, and ?becomes defined with the value? is not intrinsic assignment.
>>>

This is a change with little real effect, since if the mathematical result of adding ATOM and VALUE is not representable the program is not conforming in precisely the same way for ATOM + VALUE as it would be for ATOM + INT(VALUE,KIND(ATOM)) or indeed as it would be for INT(ATOM+VALUE,KIND(ATOM)).  Viz, the mathematical value is not representable.

In fact the only effect of the change is to make the case where VALUE is outside the range of KIND(ATOM) but ATOM+VALUE is not, e.g. ATOM==-HUGE(ATOM) and VALUE==HUGE(ATOM)+1_int64.  Since the corresponding assignment statement is valid this would be an unpleasant surprise to the user at runtime.

Given the usual hardware limitations on atomic ops, I would suggest constaining the kind of VALUE such that RANGE(VALUE)<=RANGE(ATOM).  Or even say that all values representable in the kind of VALUE shall be representable in the kind of ATOM.  Then the user will not get an unpleasant surprise at runtime but will be informed at compile time that he cannot atomically add a 128-bit value to a 32-bit atom.

Even that sort of restriction won?t help if the current values are within range but the sum is not. I think that the wording I propose leaves less to the imagination, especially regarding how ATOM ?becomes defined? in cases with mixed kinds. It is also consistent with the wording for ATOMIC_AND, ATOMIC_OR and ATOMIC_XOR.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20130808/a63853b3/attachment.html