From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailg110.ethz.ch (mailg110.ethz.ch [IPv6:2001:67c:10ec:5605::21]) by sourceware.org (Postfix) with ESMTPS id 5F1153854817 for ; Mon, 4 Jan 2021 17:55:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5F1153854817 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=student.ethz.ch Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=koenigni@student.ethz.ch Received: from mailm211.d.ethz.ch (2001:67c:10ec:5603::25) by mailg110.ethz.ch (2001:67c:10ec:5605::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 4 Jan 2021 18:54:53 +0100 Received: from [192.168.0.45] (80.218.161.162) by mailm211.d.ethz.ch (2001:67c:10ec:5603::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 4 Jan 2021 18:55:17 +0100 Subject: Re: Update on shared memory coarrays To: Iain Sandoe , Thomas Koenig CC: Fortran List , References: <79fdfc28ee95e21ba173dad5780b4e02@free.fr> <0770e8fb5b4b479afc98be8cf6221cc5@free.fr> <1a63faebd65be2a76627a7873d74c0c8@free.fr> <86fa53e3-155d-1912-8b88-b0789323ee09@netcologne.de> <2d94ef13-e12e-b941-dcb0-a9a79362f2d5@netcologne.de> <6D26C802-E6E0-473F-BB17-A9B373541980@sandoe.co.uk> <00ABD0DC-235B-4A4E-B9E0-B1200AC07EAD@sandoe.co.uk> <191C9834-F907-4CF0-B652-16E04A42B7AB@sandoe.co.uk> <5683F724-2723-4EE4-AC50-83FDB598D238@sandoe.co.uk> <2007278F-63EE-427A-BFB6-A504E96D3572@sandoe.co.uk> <116ed7ff-7cdc-6324-c6c3-33fa9b1a036c@netcologne.de> <72972030-407F-4BD7-9B6C-D6937292E906@sandoe.co.uk> From: =?UTF-8?Q?Nicolas_K=c3=b6nig?= Message-ID: Date: Mon, 4 Jan 2021 19:54:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <72972030-407F-4BD7-9B6C-D6937292E906@sandoe.co.uk> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [80.218.161.162] X-ClientProxiedBy: mailm214.d.ethz.ch (2001:67c:10ec:5603::28) To mailm211.d.ethz.ch (2001:67c:10ec:5603::25) X-TM-SNTS-SMTP: EF62EFB0F606C53CD449235D3E81B05D1A25AC07EEEFF51430B4DF67F4E8DC8A2000:8 X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, LIKELY_SPAM_FROM, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 17:55:21 -0000 Hello Iain, First of all, thank you for investigating this so thoroughly. On 04/01/2021 03:34, Iain Sandoe wrote: > Thomas Koenig via Fortran wrote: >> Am 03.01.21 um 16:42 schrieb Iain Sandoe: >>> [SHM] Shared Memory Objects >>> The functionality described is optional. The functionality described >>> is also an extension to the ISO C standard. >>> … so support is optional and a failure in partial support is not an >>> actual bug in compliance … >> >> It's a bug anyway :-) > > certainly, it’s inconvenient having different behaviout from other > platforms Yes, completely agree. > > It seems shm is not a favoured IPC mechanism for Darwin (it’s possibly > disallowed for GUI apps, according to search results - I didn’t check that) > >>> (we can file a radar, and maybe it gets fixed at some point - but >>> that’s no help to all the existing system versions) >> >> Makes sense to file a bug report with Apple.  And yes, we'll have to >> deal with this some other way. > > [for command line apps] Either mechanism for accessing shm works; > > [1] shm_open / fd / mmap / munmap > > [2] shmget / shmat / shmdt <= allocation is rounded up to the nearest > page boundary. > > Both have the constraint [on Darwin] that the size of the allocation > cannot be increased after it is set (by ftruncate() [1] or shmget() [2]). > It can be decreased (by [2] only), but it’s not clear if that actually > has any physical effect. That's a problem, since coarrays can be allocated at runtime, and we can't possibly precompute their size. To get coarrays to work, we would probably need to create new shared memory objects (with predictable names, so they can be opened from other images), but that would be a significant time investment. It also doesn't bring my hopes up that other things like pthread_{mutex,cond}attr_setpshared() will work. I think it's probably better to focus the attention on getting it to work on Linux/BSD. > > I guess that one ought to consider that a change in allocation could > trigger a copy on any system (since there might not be contiguous memory > pages available for an arbitrary increase) - so a strategy which either > allocates separae fragments for each need - or waits until the size is > known before allocation is likely to perform better on average, There's no need to have the continuous virtual memory backed by continuous physical memory, so nothing here should trigger a relocation of the actual physical memory. There are just some entries in the page table pointing to the same pages. Nicolas > > Iain >