From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C1CE53858C31 for ; Thu, 23 Mar 2023 13:52:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C1CE53858C31 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679579569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=6KY0dNPIfBhx0WbIlFwD0dC4XZgJaDFKUpqaA3kx+M0=; b=R3SJeuQXyEmjuNe+ihDHjRWJA91zPuFnKUkihBS2LbJFY86i/ahSXTnxxsJqDmIM/LVEa1 /EwHfnR67fpV9xcY5mlzll1uus81744S43OSnChsgu5aJrbS6JlCSSP6GqOY2E5YkfwR8r J9oGTan0rSOCE07MtRbBhE0IXteNDSU= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-180-31pznuJaM1itlCapVliA1w-1; Thu, 23 Mar 2023 09:52:48 -0400 X-MC-Unique: 31pznuJaM1itlCapVliA1w-1 Received: by mail-lf1-f70.google.com with SMTP id i16-20020ac25b50000000b004b565e69540so8093839lfp.12 for ; Thu, 23 Mar 2023 06:52:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679579567; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6KY0dNPIfBhx0WbIlFwD0dC4XZgJaDFKUpqaA3kx+M0=; b=B6hE4JMp0z1UhiuAmPKy1jQG2fMRqnRGp17jKN1+bQplqrwu5mJFkF1q2clJ9UCwzv 5yXtbzIRgpFYBatcYWHbLEkJAhs5yypcDNWVNU66qAH2sZnfSAbUpWGZ//A+lQRd8bGg uMCgQA42mSG3HHE3ewBHl41G94XNXNcIr8rsdZWgDaJEqNHANlkSLVbXrkg4uOL97NKG JaUUSZYwiy8nW9b7/fkyCjxHszM37kEL8o9+SHYrOtJu7syBEykIWeHofuY5pmvAq6a6 5WH7GijPrjQoXG38dF/VMhLlSdOdeRNJI6AZlF2MJcnbzdKWVbf8IYe+ngXKysucO7OY 0yUw== X-Gm-Message-State: AO0yUKUR7Ka1h9qXKYVt7hZ8MvnZXUDk/y8D3P1IkQ6OkK81HM1VXIGo hAPtRtmylNHiOP1IzkFPjD9jes0GpBBHTo3A7nkm7sY3Wa1qVMuFHWG79BezjVVHgutmgtXqzPj zJ18BE8Xd/PO9OesZAV2NDThhwdJq0kxWBklE47hrzQ== X-Received: by 2002:ac2:46fa:0:b0:4db:173e:812a with SMTP id q26-20020ac246fa000000b004db173e812amr3070372lfo.8.1679579567007; Thu, 23 Mar 2023 06:52:47 -0700 (PDT) X-Google-Smtp-Source: AK7set/bSzJftv2/S/TqFoWv60OQva7Xx3wz25e3qhwxgXoWsArq29sWS5DfxPlYJNV5Qarb7laqzRPuF9WjwzMM6Kk= X-Received: by 2002:ac2:46fa:0:b0:4db:173e:812a with SMTP id q26-20020ac246fa000000b004db173e812amr3070363lfo.8.1679579566597; Thu, 23 Mar 2023 06:52:46 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Wakely Date: Thu, 23 Mar 2023 13:52:35 +0000 Message-ID: Subject: std::jthread move assignment To: "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: While checking if we need to do anything for https://cplusplus.github.io/LWG/issue3788 I noticed that our std::jthread move assignment doesn't match the spec in the standard. The effects (after LWG 3788) are: If &x == this is true, there are no effects. Otherwise, if joinable() is true, calls request_stop() and then join(), then assigns the state of x to *this and sets x to a default constructed state. Our implementation is: jthread& operator=(jthread&& __other) noexcept { std::jthread(std::move(__other)).swap(*this); return *this; } This performs the effects in reverse! First we set other to a default-constructed state (moving it to a temporary), then we assign its original state to *this (by swapping with the temporary), then if the original state of *this was joinable() we request_stop() and join() (in the temporary's destructor). In theory the other thread could inspect the state of either *this or other when requested to stop (e.g. because it has a reference to the jthread, or the jthread is a global). If the jthread has been modified before the request_stop() call, that's observable. However, I think that would be a data race because we're in the process of calling non-const member functions on both *this and other. So if the running thread accesses either of those objects, the behaviour is undefined. So it's OK that we do the effects in a different order. Does anybody disagree?