From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ammarfaizi2@gnuweeb.org>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NO_DNS_FOR_FROM autolearn=no
	autolearn_force=no version=3.4.6
Received: from localhost.localdomain (unknown [182.253.183.169])
	by gnuweeb.org (Postfix) with ESMTPSA id 24CEF832B5;
	Sun, 12 Mar 2023 19:40:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org;
	s=default; t=1678650032;
	bh=IbN/z2Pe3YrWguscbAD85y5aizoK7hnKxJlc1Q2lGTw=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
	b=cTZ84RMpzzmeXtZ/G/QQ7leNfAwDNIXnOjqPI/Ol4PwCwCh3gQIe2JeJsKEyWih2N
	 71yfFynd0MAE0jApRwbPr3bFSK5lY4sXAAmCb8XAhO8CGdNweVc6qXn5NpIKcZ5TGW
	 JpdmAQQkVC9e75EJM9z2ey8AnX9tyWdNWpVw96MCo+RpZhqpbg+pdMxRfWBT/99VI+
	 017F6eemIwViOrI0U7ZswM3icvfWvwNC5R+Z+Ws1sC4tnY2kv3rGtTDfcVDiug9Nj1
	 qNq/SfKeahnuDmCw/TVwGIFEX3394uzVCcE3DRDgXNRegcriz1g5VuIVtgYMEUlyoD
	 S0OooYwHCFMBA==
From: Ammar Faizi <ammarfaizi2@gnuweeb.org>
To: Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>
Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>,
	Irvan Malik Azantha <irvanma@gnuweeb.org>,
	GNU/Weeb Mailing List <gwml@vger.gnuweeb.org>
Subject: Re: [RFC PATCH v1 0/3] Fix undefined behavior in the C++ mutex implementation
Date: Mon, 13 Mar 2023 02:40:19 +0700
Message-Id: <167864999174.1162888.14444030353924027192.b4-ty@gnuweeb.org>
X-Mailer: git-send-email 2.34.1
In-Reply-To: <20230311112810.3670483-1-alviro.iskandar@gnuweeb.org>
References: <20230311112810.3670483-1-alviro.iskandar@gnuweeb.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
List-Id: <gwml.vger.gnuweeb.org>

On Sat, 11 Mar 2023 11:28:07 +0000, Alviro Iskandar Setiawan wrote:
> The current C++ mutex implementation is undefined behavior, specifically
> in the cond_wait() function because std::unique_lock<std::mutex> is
> constructed with std::defer_lock while the same thread has acquired the
> lock. Also, right after that defer_lock, std::condition_variable calls
> wait() with a unique lock, not in a locked state.
> 
> In such a situation, the correct construction is using std::adopt_lock.
> However, using std::adopt_lock leads to another issue. The issue is the
> lock will be released upon return in the cond_wait(). To solve the
> problem, introduce a new helper function, __cond_wait() which will
> release the lock with std::adopt_lock and then call it from cond_wait().
> The cond_wait() then acquires the lock again before it returns. The
> result is that we correctly fulfill the __must_hold() semantic while
> conforming to the C++ mutex implementation.
> 
> [...]

Applied, thanks!

[1/3] MAINTAINERS: Add myself as the thread maintainer
      commit: 5be6c427164522be650985c93595615c4f5c00e2
[2/3] core/thread: Fix undefined behavior in the C++ mutex implementation
      commit: bd84193e908c455c7c0c7f94a914d46b75557815
[3/3] configure: Introduce `--cpp-thread` option
      commit: 45b140357906d810f023ed1735a2b6585f4a5dce

Best regards,
-- 
Ammar Faizi