From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Wed Aug 27 21:41:15 2025 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 04EC1356BE6; Wed, 27 Aug 2025 21:41:15 +0200 (CEST) Delivered-To: sc22wg14@open-std.org X-Greylist: delayed 374 seconds by postgrey-1.34 at www5.open-std.org; Wed, 27 Aug 2025 21:41:14 CEST Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by www.open-std.org (Postfix) with ESMTP id 99256356BDA for ; Wed, 27 Aug 2025 21:41:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1756323673; 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=bGQqx2/my8J04Vjn9hiCOgr+NqtqlsEAsu2/YMWprP4=; b=fFq5IDLEMuM028xIj4mwAuJOFqTgnbkdIiIYepn4i1q8dWjAFhxxRRt+30YYWnzt2ySAUG CVp+TpqzKzQjJWXY8tUqMMFYE3VSdho3bpiIRiv5WLAobrQmSVty8EQmW428+DUb6RMUlU cDHxyk3FT4Rnxr0jM7VPY6oWZMgg01I= Received: from mail-yx1-f69.google.com (74.125.224.69 [74.125.224.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-26-8Eyro8f6M6en_MtCWGPROw-1; Wed, 27 Aug 2025 15:34:55 -0400 X-MC-Unique: 8Eyro8f6M6en_MtCWGPROw-1 X-Mimecast-MFC-AGG-ID: 8Eyro8f6M6en_MtCWGPROw_1756323295 Received: by mail-yx1-f69.google.com with SMTP id 956f58d0204a3-5fae5f738cdso303519d50.1 for ; Wed, 27 Aug 2025 12:34:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756323295; x=1756928095; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bGQqx2/my8J04Vjn9hiCOgr+NqtqlsEAsu2/YMWprP4=; b=YQq4+R3CmZt3ezhFtvyirNkxu4yCH4XPOhRKHXgXl6NGCfuncg63t4AAqkDl3QFGsf 9AjQWHK1RqEwSqkFDgZg9owHhUezFPKjEdFjlZYiBbHAMqySLidKptRDKUnAiabB09mL cGkLUndqgTciwJGJR3Itzld4vFOBYk6TuG0/3Zm9eDz9Aac3MYxMAD1P0oKoBf+mQ9DM NVMd4Y05lgHHyAC3ZPSE9jIMkAyAt6LhoNRmBmpTNGDI6JV9K/f1DgkA1i+1PXVO5PXA oy/wj7g4dtSwHWYQ4sy0HMorhvDPX9KNuz69VDnETkOj0hgrerkFqxDoRkqQ2pqBjc5+ B6jw== X-Gm-Message-State: AOJu0Yzsn8iJrsFne2EDJZi5E0u6F7kyJ0p9PGesRqWkogm+Mas8qh/W 5k4IPl9DqiUUUQr8+7RdgkRJIneXDeKbCXt7CKf+AKoM6bxyj0x/LDxhwl4zYj8Hmoyg1uXmMkS X5Rm6M8q3oZg91oHl1bYjjCFOLMofFoUVYbrR2GOsoqEnQeSPQyl8jzzCDSv9pntoIkhE+ukq0b Zp6gf+WWTHT5u8pKKI6Z4MZS1i7oM3CLfb4SSLdL2DVg== X-Gm-Gg: ASbGnctbNo4yoGqm1VKjKnzJNXjHHWTeasrFnK5C4qMa/Wu8SgmPXIEqOnzkLoI/l+R m9M+yNVZV8geCxcjOPh4w8CSUTQjwq8BI38X5Qcu09MgUqNNaCr+DoGeJavMnLVybfwvK4f73ZL 6HxpCbDA3Z5Vl5SbHx5KdC X-Received: by 2002:a05:6902:1006:b0:e95:3397:c010 with SMTP id 3f1490d57ef6-e96e031cb0amr7501815276.0.1756323294957; Wed, 27 Aug 2025 12:34:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGY0XTW+0YCmPeTfU8a8LULZ6H/tArRBGUX/JqLT6whmLx3XrxU2ka9QFoGUgLDFoCjf3+z8+vjaJJbAMbPJbg= X-Received: by 2002:a05:6902:1006:b0:e95:3397:c010 with SMTP id 3f1490d57ef6-e96e031cb0amr7501790276.0.1756323294601; Wed, 27 Aug 2025 12:34:54 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Wakely Date: Wed, 27 Aug 2025 20:34:38 +0100 X-Gm-Features: Ac12FXzz7xwoo_gzZQh4pHFVxf48c4CVZOD0VTCKjA_WrrK_wcuY140ATpyaBwg Message-ID: Subject: Another daemon: waiting for condition variables To: wg14 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: PxkOd8Lqh7yYZTmed4NFWNcnNRRAT-mRpGW2eA_urhs_1756323295 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Sender: owner-sc22wg14@open-std.org Precedence: bulk Sorry for not noticing this paper sooner, but I see that N3559 was approved this week, and I'd like some clarification because the paper says it doesn't intend to make any normative change. What counts as "access to the condition variable being destroyed"? It seems pretty obvious that a call to cnd_wait should count as accessing it, but is that true until the call returns? Because that would be a normative change. So what part of a call to cnd_wait counts as "access"? The intention of the wording is to match POSIX pthread_cond_destroy which allows a pthread_cond_t to be destroyed while some threads are still executing a call to pthread_cond_wait, as long as they are no longer blocked. So if you do pthread_cond_broadcast, you can destroy the condition variable immediately, even though threads which were woken by the broadcast will not return from pthread_cond_wait until after the reacquire the associated mutex. If there are many threads that were woken, they can't all return immediately because they have to take it in turns to reacquire the mutex. POSIX is very clear about this, see the example at https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_cond_destroy.html Setting aside the stated problem with using the word "requires" here, the C23 wording seems clear to me. The precondition for calling cnd_destroy is that "no threads be blocked waiting for the condition variable". This mirrors the wording in cnd_wait that talks about being "blocked", which is a state that ends before reacquiring the mutex. So the old wording very specifically allows destroying the condvar while cnd_wait is still executing, as long as all such calls to cnd_wait have moved from the "blocked" phase to the "locks the mutex pointed to by mtx before it returns" phase. The new wording has no such precision, it just talks about "concurrent access" an I don't know what that means. Shouldn't the "fixed" wording still be specified in terms of being blocked, rather than "access"? The same argument applies to cnd_timedwait of course.