[libcxx-dev] Is a compiler-rt shared spinlock implementation of any use to libcxx?

Mon May 20 19:40:18 PDT 2019

In case nobody has mentioned this already:

libc++ provides a mechanism for users to provide their own implementations
of threading primitives.
See <__threading_support> and
http://libcxx.llvm.org/docs/DesignDocs/ThreadingSupportAPI.html for more
information.

Let's not go reinventing this wheel here.

/Eric

On Mon, May 20, 2019 at 5:05 PM JF Bastien via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

>
>
> On May 20, 2019, at 2:03 PM, Ben Craig <ben.craig at ni.com> wrote:
>
> I guess it depends if the goal is to have a spin lock class, or a sharded
> lock table.
>
> If it’s a spin lock class, then someone needs to just make the class and
> get it into some header and/or static lib somewhere.  The specifics aren’t
> super important.
>
>
> The former.
>
>
> If it’s a sharded lock table, then you need to figure out which dynamic
> library will provide it, and how that will interact with libc++ when it is
> used atop libsupc++ or built with GCC.
>
> *From:* jfbastien at apple.com <jfbastien at apple.com>
> *Sent:* Monday, May 20, 2019 3:59 PM
> *To:* Mitch Phillips <mitchphillips at outlook.com>
> *Cc:* Ben Craig <ben.craig at ni.com>; Olivier Giroux <OGiroux at nvidia.com>;
> libcxx-dev at lists.llvm.org; kostyak at google.com
> *Subject:* [EXTERNAL] Re: [libcxx-dev] Is a compiler-rt shared spinlock
> implementation of any use to libcxx?
>
> “Freestanding” is meant for a few things, of which: codebases that can’t
> have external dependencies, “bare metal” code or other embedded code. This
> sounds exactly like what you’re after.
>
> The projects are all in the same repository. You can absolutely depend on
> having it: it’s in the same repo. You therefore don’t need to duplicate
> anything.
>
>
>
> On May 20, 2019, at 1:55 PM, Mitch Phillips <mitchphillips at outlook.com>
> wrote:
>
> I'm a little confused about how said aformentioned freestanding
> implementation would work. We (GWP-ASan + Scudo) can't depend on having
> libcxx (we actually explicitly disable
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D62048&d=DwMFaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=0JDRKupnKG2FyAYi69CfJqswn5ys3q3D8nrjL8eqtQw&s=AgRXbJ1EHKQtYIn_0Ku-RB1v_LizN2Q4nVeZ595pZa8&e=>
>  using of the c++ standard library for these libraries), and I don't know
> where we could have a shared implementation live (that could be used by
> both us and libcxx).
>
> Would we have a spinlock implementation in libcxx and have that guarded by
> a macro definition before the include of <mutex>, and then keep a
> synchronised version in compiler-rt?
>
> On Mon, May 20, 2019 at 10:10 AM Ben Craig <ben.craig at ni.com> wrote:
>
> Wouldn’t all the Scudo and sanitizer things count as part of the toolchain
> implementation though?  Having pieces of the toolchain use an alternative
> name seems pretty reasonable to me.
>
> If the goal is to have a freestanding std::mutex that is implemented as a
> spin lock, well, that’s different.  I could be convinced that’s a good
> thing to have, but I’m still a bit uneasy about it.
>
>
> *From:* jfbastien at apple.com <jfbastien at apple.com>
> *Sent:* Monday, May 20, 2019 11:27 AM
> *To:* Ben Craig <ben.craig at ni.com>
> *Cc:* Olivier Giroux <OGiroux at nvidia.com>; Mitch Phillips <
> mitchphillips at outlook.com>; libcxx-dev at lists.llvm.org;kostyak at google.com
> *Subject:* [EXTERNAL] Re: [libcxx-dev] Is a compiler-rt shared spinlock
> implementation of any use to libcxx?
>
> I think what developers *use* should definitely be named std::mutex. We
> indeed want to consider how the ABI is exposed, that’s a good question for
> libc++ maintainers.
>
>
>
>
> On May 20, 2019, at 6:23 AM, Ben Craig <ben.craig at ni.com> wrote:
>
> I think it’s fine to give such a class the same interface as std::mutex,
> just please don’t actually name it std::mutex.  I would be pretty concerned
> about ABI compatibility in that situation, as well as subtle interactions
> with things like condition_variable::wait.  cxxabi::__mutex, or almost any
> other identifier would be fine.
>
> *From:* libcxx-dev <libcxx-dev-bounces at lists.llvm.org> *On Behalf Of *Olivier
> Giroux via libcxx-dev
> *Sent:* Friday, May 17, 2019 7:55 PM
> *To:* JF Bastien <jfbastien at apple.com>; Mitch Phillips <
> mitchphillips at outlook.com>
> *Cc:* kostyak at google.com; libcxx-dev at lists.llvm.org
> *Subject:* [EXTERNAL] Re: [libcxx-dev] Is a compiler-rt shared spinlock
> implementation of any use to libcxx?
>
> That’s what makes the most sense to me, include <mutex> with a macro that
> freestanding would also use. Inside of that, I would have an implementation
> of standard mutex backed by atomics and the atomic_wait/atomic_notify_*
> functions, themselves configured with a macro to not rely on the OS in
> freestanding implementations.
>
> Olivier
>
> *From: *libcxx-dev <libcxx-dev-bounces at lists.llvm.org> on behalf of JF
> Bastien via libcxx-dev <libcxx-dev at lists.llvm.org>
> *Reply-To: *JF Bastien <jfbastien at apple.com>
> *Date: *Friday, May 17, 2019 at 4:40 PM
> *To: *Mitch Phillips <mitchphillips at outlook.com>
> *Cc: *"kostyak at google.com" <kostyak at google.com>, "
> libcxx-dev at lists.llvm.org" <libcxx-dev at lists.llvm.org>
> *Subject: *Re: [libcxx-dev] Is a compiler-rt shared spinlock
> implementation of any use to libcxx?
>
> I think it makes sense for libc++ to have a version of mutex which has the
> same API as the standard one, but for “freestanding” platforms such as
> yours. A flavor which mostly just spins and yields as in your review.
>
> I’m not sure how to best turn it on, though. Should it be controlled by a
> macro, and otherwise it just looks like you’re using <mutex>?
>
>
>
>
> On May 17, 2019, at 1:49 PM, Mitch Phillips via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> In a recent discussion
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D61923-231503272&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=yw9dJtPZSvMNi00nrRSUlnN4NTQzKvXzHbd5w8ShH8A&s=uW10gtroz30NxGIUU3BvNH5efGnzv2tds3P49eY5ri4&e=>
>  from the reviews of GWP-ASan
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D60593&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=yw9dJtPZSvMNi00nrRSUlnN4NTQzKvXzHbd5w8ShH8A&s=rKVj5vHVGEsEZRjMkiN2X6e0bAfdTY7iVW0laX2AO8o&e=>,
> it was mentioned that I should probably consult with cxx-dev to see whether
> they'd be interested in a common spinlock implementation.
>
> The problem is:
>  - Scudo hardened allocator (compiler-rt/lib/scudo) requires its own
> spinlock as it can't use the C++ standard library due to Fuchsia
> requirements.
>  - GWP-ASan (as it's packaged into Scudo) also requires a spinlock.
>  - Compiler-rt sanitizer_common also can't use c++ stdlib, and has its own
> spinlock. We can't reuse the sanitizer_common spinlock for Scudo/GWP-ASan
> as it's currently tightly coupled into sanitizer_common, and Scudo+Fuchsia
> can't afford the code size overhead of pulling the entire sanitizer_common
> library.
>
> The plan was to basically write a small standalone spinlock implementation
> that can be used by all three of these requirements. Would libcxx benefit
> by us making this an llvm-common spinlock rather than compiler-rt-common?
> If so, are there any requirements that we need to be aware of?
>
> Cheers,
> Mitch.
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_libcxx-2Ddev&d=DwQGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=y8mub81SfUi-UCZRX0Vl1g&m=yw9dJtPZSvMNi00nrRSUlnN4NTQzKvXzHbd5w8ShH8A&s=SLhw06SYT_9fwfHOjm_nzQZ0LuPvmMe_b2gjd-VEFcc&e=>
>
>
> ------------------------------
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
>
>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190520/eb3f27ba/attachment-0001.html>