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

[John Reid]

Lionel, Steve wrote:
> Iwrote:
>
> <<<
>
> 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?

The EVENT POST statement normally has a coindexed event variable, so it 
is possible for two images to post the same event variable in unordered 
segments. In this case, which posting first increments the event 
variable is processor dependent. This is perhaps the point you wish to make.

Cheers,

John.
>
> 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
>
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>