From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 4071C385800D for ; Mon, 1 Aug 2022 22:07:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4071C385800D Received: by mail-pl1-x62d.google.com with SMTP id x23so3076847pll.7 for ; Mon, 01 Aug 2022 15:07:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MqriV8Jkf1hitjL24DqqQHvHj2/rahwWu109uF5Jjg4=; b=nDontnUTdsRYoCLcM6ydnw+PUSKwnqjuCMLj+9Fy5b+kcxbzauMY9ynVDaaQBZHpT5 8Z39DrZR0ABZum1Tx2yPGixC7zTs31+dQ1X3ahSBw5ZtFszv+kZ9HLtsrvoXyfO6lBO+ FRgLWAl/khDOkeDHbjnGKfJmMQZRSQvj3LfTzt3hi1RiJVpnbs8Iu6gFYCZbQ4uQqBXr WZF+XHeLYKvhyVglTsMVti8VrjvH3W5iEmljsE9JmeZQ6zkJQ82hK2bL114soPIE4kH9 coP80/CSImgNqyNqRmq+SfBcmznBuN2z2s2UH3GIR6oumdcVGhZyf0Qdd9UFWNNQ83iZ sMGw== X-Gm-Message-State: ACgBeo3ntw2BOmcD5E6KXIRupoLBHknIyj0MIvucXj7RJfpeBFDs+ZAZ Rk6q6ZDhueEO/RivTFFzwrqwR1wlnK6kbBf0DR8= X-Google-Smtp-Source: AA6agR5Alr5MtzWQK1Tp4rl7kadQ0DmhHtZWBrJXNcoBmzYh4iHrmHJ43lrVWwnxkk3Lwdx5CFBznHYq94UdaQHvYRk= X-Received: by 2002:a17:902:b08a:b0:16c:68b6:311 with SMTP id p10-20020a170902b08a00b0016c68b60311mr17512802plr.166.1659391664674; Mon, 01 Aug 2022 15:07:44 -0700 (PDT) MIME-Version: 1.0 References: <9f29c0c4-7b2a-3d95-5a62-837b5c352d79@embedded-brains.de> In-Reply-To: From: =?UTF-8?B?Sm/Dq2wgS3LDpGhlbWFubg==?= Date: Tue, 2 Aug 2022 00:05:07 +0200 Message-ID: Subject: Re: pthread_mutex_timedlock() vs. clock_settime() To: Sebastian Huber Cc: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.1 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 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-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2022 22:07:47 -0000 Hi Sebastian, About atomic operations and its memory barriers. It gives you additional synchronization to target 1 problem. You don't have any promise on what time or order your code is executed on assembly level and on the stack. GCC can change program flow. regards, Jo=C3=ABl On Mon, Aug 1, 2022 at 10:11 PM Jo=C3=ABl Kr=C3=A4hemann wrote: > > Hi Sebastian, > > I am unsure where are your doubts in what I told you: > > #1 conditional locks always use 2 condition variables with logical and > #2 signal only waiting conditions > > The points above apply to any conditional lock. Thought, there is an > exception for synchronized threads. But your threads aren't > synchronized. > > If your conditional lock is invoked more than once: > > #3 do initial sync > #4 provide additional variables to avoid override by previous run. > Yes, we need some tuples. If you use three you can even detect > dead-locks. > #5 your threads may run on a different CPU even physically. You need > atomic operations. > > I am willing to do further explanation, but what I am telling you is > based on experience with AgsThread::clock() > > https://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags_t= hread.c?h=3D4.3.x#n2302 > > This code was reworked by me different times to fine tune it. First I > was using the POSIX API and migrated later to GLib. > > regards, > Jo=C3=ABl > > On Mon, Aug 1, 2022 at 6:31 PM Sebastian Huber > wrote: > > > > Hello Jo=C3=ABl, > > > > this is just a test case and not a real application. There is only a > > main thread and a worker thread. The worker thread should just block o= n > > an synchronization object and then wait for a time out (or it is > > cancelled). The main thread uses a simple sleep(1) to hopefully ensure > > that the worker task had enough time to block on the synchronization > > object under test. There are different action and done events. Since a > > mutex is used, there is no need for atomic objects. > > > > -- > > embedded brains GmbH > > Herr Sebastian HUBER > > Dornierstr. 4 > > 82178 Puchheim > > Germany > > email: sebastian.huber@embedded-brains.de > > phone: +49-89-18 94 741 - 16 > > fax: +49-89-18 94 741 - 08 > > > > Registergericht: Amtsgericht M=C3=BCnchen > > Registernummer: HRB 157899 > > Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thom= as D=C3=B6rfler > > Unsere Datenschutzerkl=C3=A4rung finden Sie hier: > > https://embedded-brains.de/datenschutzerklaerung/