From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57615 invoked by alias); 20 Feb 2018 20:05:05 -0000 Mailing-List: contact libstdc++-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libstdc++-owner@gcc.gnu.org Received: (qmail 57394 invoked by uid 89); 20 Feb 2018 20:04:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy= X-HELO: mail-it0-f45.google.com Received: from mail-it0-f45.google.com (HELO mail-it0-f45.google.com) (209.85.214.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Feb 2018 20:04:46 +0000 Received: by mail-it0-f45.google.com with SMTP id a203so6616776itd.1 for ; Tue, 20 Feb 2018 12:04:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YtaEzSUUB84abG8fq0mKVFWFgS9FTLz0HU9qe+luQ7c=; b=E3Rhd9lgjVInoDuzN660j4fEQkRnNzBZhruGB6i6725cCpFKzWZ0+JxCjMjg1tY//B UMqA+IkrE/OloHHUy+tkQTcYEmQNbZQdzMSK9iLEmzdflf7OXOwLWLNbSOPQYB9TtdDU 759hCGM4mNigyxKDFtBwNddx7pOrtQ/jCO6XBhpdu+nlKKV49IJQFqEnuNBYdG0FZaDT mww/1slQXpuTKy+mfavB9h8UKx3AxY6EsXg/TZMH90QoaL3thGH2H2Luv483WOb1UAqX +q5I9/DfD+U8MCnP+3BrgAgj6l0Zk6Om8v5KZ4RrwbA8HGR2krVVyK9a1G8w2jagUT6b aRIg== X-Gm-Message-State: APf1xPChyhLbBpjBgpNB1CKf3lIaPoGM8u8ayfyqkTJXAtgJtm08Q/fG ycV2jmkYAzbOSNqkVSy6EKSvhYHed4SfmZ0aUCs= X-Google-Smtp-Source: AH8x2270ziIbU/WhizmuRFUmoLTBGT0t8GLBefBQsZh6LNGBFuSxz90DjPVNSxZeXB9UX1UmVznUMAebIrS4APll0Ek= X-Received: by 10.36.108.19 with SMTP id w19mr100883itb.65.1519157085120; Tue, 20 Feb 2018 12:04:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.83 with HTTP; Tue, 20 Feb 2018 12:04:44 -0800 (PST) In-Reply-To: References: <1519054665.16577.13.camel@t-online.de> From: Jonathan Wakely Date: Tue, 20 Feb 2018 20:05:00 -0000 Message-ID: Subject: Re: shared_ptr's reference counter thread safety on ARM Cortex-M To: karel pavlata Cc: Oleg Endo , "libstdc++" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00016.txt.bz2 On 19 February 2018 at 19:33, karel pavlata wrote: > > > D=C5=88a pondelok 19. febru=C3=A1ra 2018 Jonathan Wakely nap=C3=ADsal(a): > >> On 19 February 2018 at 15:37, Oleg Endo wrote: >> > Even though on such systems there might not be real threads, atomic >> > operations can still be useful, e.g. when sharing variables between the >> > "main thread" and interrupt handlers (adhoc preemptive threads so to >> > say). >> >> It would be fairly simple to add a new mode that means libstdc++ >> should use atomic ops, but not provide , etc. >> >> Somebody who cares about it just needs to do the work. > > > This systems can (and usually do) run a lightweight non-posix RTOS so it > would be usefull. I'm not familiar with gcc's internals but will try to l= ook > into that. If anybody can provide hints and/or caveats they're welcome. I think the simplest approach would be to add a new --enable-xxx option to libstdc++, which would be done by adding a new macro to libstdc++-v3/acinclude.m4 and then using it in libstdc++-v3./configure.ac That should define a new preprocessor macro which overrides the selection of __default_lock_policy in lisbtdc++-v3/include/ext/concurrence.h and the behaviour of __exchange_and_add_dispatch and __atomic_add_dispatch in libstdc++-v3/include/ext/atomicity.h so that they don't only depend on #ifdef __GTHREADS (which is not defined for --enable-thread=3Dsingle).