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.