Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Alessandro and Tobias,

I have been through the patch to check for obvious bloopers but can
find none, as expected given the author :-)

I would dearly like to see the testcases at the same time as the patch
but.... I think that the commit should be made sooner, rather than
later. Given its nature, I think that it is pretty safe at this stage
of the 6.0.0 lifecycle and so I say OK for trunk.

Cheers

Paul

On 25 November 2015 at 18:24, Alessandro Fanfarillo
<fanfarillo.gcc@gmail.com> wrote:
> Dear all,
>
> in attachment the previous patch compatible with the current trunk.
> The patch also includes the changes introduced in the latest TS 18508.
>
> Built and regtested on x86_64-pc-linux-gnu.
>
> PS: I will add the test cases in a different patch.
>
> 2015-04-29 9:55 GMT+02:00 Tobias Burnus <tobias.burnus@physik.fu-berlin.de>:
>> Dear all,
>>
>> attached patch fixes a bug and implements EVENTS. I think the patch is
>> finished, but I still have to extend the test cases, to re-read the
>> patch and to write a changelog. As I am not sure how soon I will able
>> to do so, I follow the paradigm: release soon, release often and post
>> it here. Comments and reviews are welcome.
>>
>> The patch fixes two bug in the "errmsg" handling, found by Alessandro:
>> I don't pass on the address of the actual argument and in libcaf_single,
>> I copy only 8 characters (sizeof pointer) instead of all of the the
>> characters of the error message.
>>
>> Regarding events: Events is a way to permit barrier/locking-free
>> programming: One sends the finished data to an other image and then
>> tells that image that the data is there ("event post(msg_var[idx])").
>> That image can then either wait for the event by querying the status
>> on the local variable ("event wait(msg_var)") or only check the status
>> and if it is not ready do something else (e.g. another iteration);
>> that's done via "call event_query(msg_var, count)".
>>
>> Technically, event_post works like atomic_add(msg_var[idx], 1) and
>> event_query like "atomic_ref(msg_var, count)". event_wait is the same
>> as event_query plus a spin/sleep loop waiting for the status change,
>> followed by an atomic_add(msg_var, -until_count). Except that
>> event_post/event_wait are image control statements. (Otherwise it
>> could happen that the event is there before the data for which the
>> event has been posted.)
>>
>> Regarding the implementation in this patch, the limitations are the
>> same as for locking: Currently, neither lock_type nor event_type
>> variables are permitted as (nonallocatable) components
>> of a derived type - and type extension of them also not yet supported.*
>>
>> The spec can be found at http://bitly.com/sc22wg5 -> 2015 -> TS draft
>> or directly at
>> http://isotc.iso.org/livelink/livelink?func=ll&objId=17064344&objAction=Open
>>
>> Tobias
>>
>>
>> * Doing so is not really difficult but I need to handle cases like
>> the following. For "allocatable" with SOURCE= I also need to handle
>> it with polymorphic types.
>>
>> type t1
>>   type(event_type) :: EV
>>   type(lock_type) :: LK
>> end type1
>> type t2
>>   type(t1) :: a(5)
>> end type t2
>> type t3
>>   type(t2) :: b(8)
>> end type t3
>>
>> type(t3), save :: caf(3)[*]
>>
>> For those, I need to call _gfortran_caf_register for
>>   caf(:)%b(:)%a(:)%ev and caf(:)%b(:)%a(:)%lk
>> Looping though all array references.
>>
>> Similar for
>>   type(t3), allocatable :: caf2(:)[:]
>>   allocate(caf2(n)[*])
>> for the allocate call.



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx