Message ID | 20230620171731.230-1-luoyonggang@gmail.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 91E023857C4F for <patchwork@sourceware.org>; Tue, 20 Jun 2023 17:18:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91E023857C4F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1687281490; bh=5c9U48KdEVWp1q7clJkl4OkwaWv+6jxA1JeUBYsgMcA=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=tgLVjWPpjNSfFh0SkuqQjp3P4uQRoOW21MeiKAu2wq9um6kLep8xwlA4JEOlXRAAy CK57FzRGfpcFAGGzJm8t7n1j4EX/4mzg5sV4e6hKlXFYYbmMh6kJCOHmd7Vg8S/KeX R2Vi4sE+vG4HLe7ffiFKtjppdhlw4lXyw1WPK6xk= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id 0EDAF3858D1E for <libc-alpha@sourceware.org>; Tue, 20 Jun 2023 17:17:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0EDAF3858D1E Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-25edd424306so1528167a91.1 for <libc-alpha@sourceware.org>; Tue, 20 Jun 2023 10:17:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687281466; x=1689873466; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5c9U48KdEVWp1q7clJkl4OkwaWv+6jxA1JeUBYsgMcA=; b=EyY7gSViIMVkr9bHXxdSlJjzFfdTToMUl7kc/nxxVWLVwVQI8uj5YIN7ICK9PTElxS FR56vCsEktJ7Q6jfnMdWVoIfGPWzmPfKVCJshnUo9VyflIGMBrJ1sP9oCWw07CRiMnrA i++wO77ezYNdIcY0KgqoEBiBLrblUTtaff37YzzgZ89oRpIJhI6vfzu7YihO9bopkpZ2 MmOrA6Y3J3DdUiPPO/3NNbv5QrJI6L2TmNO4xBfgYo880a4P2kozq8wn4co8c1DpDoyi eievMtMqFu5OyorHIpv6KoYbCaNGfC9soqDIuGtDLKoG1hf2PXWF3gDMIE2U55m7DPr8 goPA== X-Gm-Message-State: AC+VfDxHZRuj2ajAA8enGROerOE5eDxPG22LsAFD0eIq8d+/ZAJiLv8n +RYD6k0B8cli4IgPSypHQhuqVoKnJQUnsUM/ X-Google-Smtp-Source: ACHHUZ6Nk7qVwP4gri53DGlV/hgU7JAbpDLwZ7lWqStaVEoRoOMoTH4AIc6uyHxsjgZvAnK/jWhtUg== X-Received: by 2002:a17:90b:3542:b0:25b:f0fa:ab3a with SMTP id lt2-20020a17090b354200b0025bf0faab3amr3448788pjb.18.1687281465560; Tue, 20 Jun 2023 10:17:45 -0700 (PDT) Received: from localhost.localdomain ([103.94.185.75]) by smtp.googlemail.com with ESMTPSA id r23-20020a634417000000b005143448896csm1652930pga.58.2023.06.20.10.17.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jun 2023 10:17:45 -0700 (PDT) To: Jens Gustedt <jens.gustedt@inria.fr>, libc-alpha@sourceware.org Cc: Florian Weimer <fweimer@redhat.com>, Yonggang Luo <luoyonggang@gmail.com> Subject: [PATCH v2 0/4] c2y proposal add monotonicwait support for mtx and ctx Date: Wed, 21 Jun 2023 01:17:27 +0800 Message-Id: <20230620171731.230-1-luoyonggang@gmail.com> X-Mailer: git-send-email 2.39.0.windows.1 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Yonggang Luo via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Yonggang Luo <luoyonggang@gmail.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
c2y proposal add monotonicwait support for mtx and ctx
|
|
Message
Yonggang Luo
June 20, 2023, 5:17 p.m. UTC
For c11 threads, the mtx and cnd doesn't support for monotonic timedlock and timedwait; So add two proposal function mtx_timedlock_base cnd_timedwait_base to do that. The protype of these two functions is: int mtx_timedlock_base(mtx_t *restrict m, int time_base, const struct timespec *restrict ts); int cnd_timedwait_base(cnd_t *restrict c, mtx_t *restrict m, int time_base, const struct timespec *restrict ts); The time_base at least can be TIME_UTC/TIME_MONOTONIC, the implementer can implement it with any provided TIME_* base parameter provided in c2y time.h, if TIME_MONOTONIC can not natively supported, fallback to TIME_UTC should provided, for other TIME_* base parameter, it's implementer's choice. Yonggang Luo (4): clang-format: should format with 2 space and do not usage tab time: Implement c23 timespec_get base c11: Switch to use pthread_mutex_clocklock and pthread_cond_clockwait to implement cnd and mtx lock and wait c2y: Add function cnd_timedwait_base and mtx_timedlock_base .clang-format | 4 +- conform/data/threads.h-data | 2 + htl/Versions | 5 + nptl/Versions | 5 + sysdeps/pthread/Makefile | 2 + sysdeps/pthread/cnd_timedwait.c | 8 +- .../{cnd_timedwait.c => cnd_timedwait_base.c} | 58 +++++----- sysdeps/pthread/mtx_timedlock.c | 6 +- .../{mtx_timedlock.c => mtx_timedlock_base.c} | 56 +++++----- sysdeps/pthread/threads.h | 18 ++++ sysdeps/unix/sysv/linux/Versions | 6 ++ sysdeps/unix/sysv/linux/cnd_timedwait.c | 4 +- .../{cnd_timedwait.c => cnd_timedwait_base.c} | 24 +++-- sysdeps/unix/sysv/linux/mtx_timedlock.c | 4 +- .../{mtx_timedlock.c => mtx_timedlock_base.c} | 100 +++++++++--------- sysdeps/unix/sysv/linux/thrd_priv.h | 10 ++ time/time.h | 13 ++- time/timespec_get.c | 51 ++++++++- 18 files changed, 240 insertions(+), 136 deletions(-) copy sysdeps/pthread/{cnd_timedwait.c => cnd_timedwait_base.c} (70%) copy sysdeps/pthread/{mtx_timedlock.c => mtx_timedlock_base.c} (75%) copy sysdeps/unix/sysv/linux/{cnd_timedwait.c => cnd_timedwait_base.c} (60%) copy sysdeps/unix/sysv/linux/{mtx_timedlock.c => mtx_timedlock_base.c} (60%)
Comments
I think it's a misrepresentation to refer to this as a C2y proposal. You're proposing a new GNU interface and should describe it as such and justify it as such. Maybe you intend to propose it for C2y or C3x (whatever the next C standard revision is - we haven't decided on a schedule and that's not up for discussion again before the October meeting at the earliest), but I don't see a WG14 document with such a proposal, and proposals for the next C standard revision can't now be taken until the C2x ballots (DIS, possibly FDIS) have completed, some time in 2024.
On Wed, Jun 21, 2023 at 4:45 AM Joseph Myers <joseph@codesourcery.com> wrote: > > I think it's a misrepresentation to refer to this as a C2y proposal. > You're proposing a new GNU interface and should describe it as such and > justify it as such. Maybe you intend to propose it for C2y or C3x > (whatever the next C standard revision is - we haven't decided on a > schedule and that's not up for discussion again before the October meeting > at the earliest), but I don't see a WG14 document with such a proposal, This is a prepare for such a proposal, I asked Jens Gustedt before about such a proposal, He suggest me try do the implementation in libc first, And that's make sense, and it's make me found the properly function prototype for this. It's doesn't need to be merged as soon as possible, but give us an indication that the correct direction to achieve monotonic mtx/cnd lock/wait support in C2y or C3x, And if that's direction is correct, I would like to use it in project mesa first and waiting the C2y or C3x to be appeared with such a proposal. > and proposals for the next C standard revision can't now be taken until > the C2x ballots (DIS, possibly FDIS) have completed, some time in 2024. > > -- > Joseph S. Myers > joseph@codesourcery.com -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
On Wed, 2023-06-21 at 14:52 +0800, 罗勇刚(Yonggang Luo) via Libc-alpha wrote: > It's doesn't need to be merged as soon as possible, but give us > an indication that the correct direction to achieve > monotonic mtx/cnd lock/wait support in C2y or C3x, And if that's direction > is correct, I would like to use it in project mesa first and waiting > the C2y or C3x to be appeared with such a proposal. Then you should use [PATCH RFC] in the subject. Without "RFC" it's assumed the author consider the patch ready for git master.