From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124191 invoked by alias); 25 Nov 2015 22:28:33 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 124169 invoked by uid 89); 25 Nov 2015 22:28:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SEM_URI,SEM_URIRED,SPF_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ob0-f173.google.com Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 25 Nov 2015 22:28:30 +0000 Received: by obdgf3 with SMTP id gf3so50325471obd.3; Wed, 25 Nov 2015 14:28:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.174.201 with SMTP id bu9mr25512618oec.37.1448490508605; Wed, 25 Nov 2015 14:28:28 -0800 (PST) Received: by 10.202.83.141 with HTTP; Wed, 25 Nov 2015 14:28:28 -0800 (PST) In-Reply-To: References: <20150429075505.GA21015@physik.fu-berlin.de> Date: Wed, 25 Nov 2015 22:28:00 -0000 Message-ID: Subject: Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS From: Paul Richard Thomas To: Alessandro Fanfarillo Cc: Tobias Burnus , gcc-patches , gfortran Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00168.txt.bz2 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 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 : >> 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