From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 5B9883858285 for ; Mon, 1 Aug 2022 14:46:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5B9883858285 Received: by mail-pf1-x434.google.com with SMTP id f28so2577669pfk.1 for ; Mon, 01 Aug 2022 07:46:39 -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=5wpEz6B5pWD3Ri4UUOpC9T+Ma7Eo6uPS6FuEOwo0o9c=; b=NfEVavNnX356DV+ovsGOqSIFykpcCSL5fcBfTw74nT+NvU+I1CduJg6h5kZ76S25aq t+FllIicdg2wdjhBzvxzx+utngDKui59tibwf5g2n7NJ79aioKTn8zBQwH13Fwx+hS2w oc/P7ZdQmv6nPlQcdwv7AnKRSG4uQIOEBJn2Ht5vXl8iiZnWRApkHB2PaVZm6H2XCoLC N0X/Vmu6TZCwTFYLX5DkR5uJXp+47utk7HqxkJz3jyC6a7vbcTntmufViCbJEgYRCWOD WuLkW7W6MFagBY3ILv2Uc7fp3Dq2Qr3DCQCowoh/fRJDghEHICtNmWJMcJCikVlerahH qfew== X-Gm-Message-State: AJIora/WvVSTX+3GlKRISVHCLybhLhaasswBtlPDA3719YRuCsU5zD71 iZBX6+opvU/KNA+CHj/IzTQhgLxZAJ6nTKxO80VbqRcuQEk= X-Google-Smtp-Source: AGRyM1vALpORELlEVXAPTL0RGJDiOj9fd5W4jIXJUPwGru4H0WIQX0mLozw1wkTMQDwJZ9RVMrXeZkHDIRt4mwUY8+s= X-Received: by 2002:a05:6a00:a08:b0:52b:fd6e:b198 with SMTP id p8-20020a056a000a0800b0052bfd6eb198mr16836912pfh.53.1659365198386; Mon, 01 Aug 2022 07:46:38 -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: Mon, 1 Aug 2022 16:44:00 +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.7 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 14:46:41 -0000 Hi Sebastian, Since you are new to parallelism, make sure you know about cache coherency and its implications. https://www.intel.com/content/dam/support/us/en/documents/processors/pentiu= m4/sb/25366821.pdf There are different synchronization scenarios. 1. hit and run, you can use ordinary boolean variables in your conditional = lock 2. continuously synchronization within a loop, use atomic boolean variables in your conditional lock The second case is different. You probably want to take advantage of atomic operations memory barrier behaviour. regards, Jo=C3=ABl On Mon, Aug 1, 2022 at 1:59 PM Jo=C3=ABl Kr=C3=A4hemann wrote: > > Hi, > > I co authored an article, check the section about working with parallelis= m: > > https://opensource.com/article/21/11/community-code-stories > > regards, > Jo=C3=ABl > > On Mon, Aug 1, 2022 at 1:51 PM Jo=C3=ABl Kr=C3=A4hemann wrote: > > > > Hi Sebastian, > > > > You should inform yourself better about the topic. Maybe read a manual > > about conditional locks. Since you are doing it wrong. > > > > All conditional locks take 2 condition variables, in order to prevent > > race-condition. > > > > See for example here: > > > > https://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/thread/ags= _thread.c?id=3D393da4d9fdc6c50ef3ab8eab27b562c85bd57664#n2002 > > > > Or check this for condition: > > > > ~~~~ > > > > volatile int is_wait; > > volatile int is_done; > > > > static pthread_mutex_t mutex =3D PTHREAD_MUTEX_INITIALIZER: > > static pthread_cond_t cond =3D PTHREAD_COND_INITIALIZER; > > > > pthread_mutex_lock(&mutex); > > > > if(g_atomic_int_get(&is_wait) && > > !g_atomic_int_get(&is_done)){ > > g_atomic_int_set(&is_wait, TRUE); > > > > while(g_atomic_int_get(&is_wait) && > > !g_atomic_int_get(&is_done)){ > > pthread_cond_wait(&cond); > > } > > } > > > > pthread_mutex_lock(&mutex); > > > > > > ~~~~ > > > > Then later signal: > > > > ~~~~ > > > > g_mutex_lock(&mutex); > > > > g_atomic_int_set(&is_done, TRUE); > > > > if(g_atomic_int_get(&is_wait)){ > > pthread_cond_signal(&cond); > > } > > > > g_mutex_unlock(&mutex); > > > > ~~~~ > > > > regards, > > Jo=C3=ABl > > > > On Mon, Aug 1, 2022 at 11:51 AM Jo=C3=ABl Kr=C3=A4hemann wrote: > > > > > > Hi, > > > > > > Sorry, you are right. Might be your conditional lock is buggy. I thin= k > > > of a race-condition ending in a dead-lock, because you don't do any > > > initial sync. > > > > > > ^^ this is really probable, but let me check later. > > > > > > regards, > > > Jo=C3=ABl > > > > > > > > > On Mon, Aug 1, 2022 at 10:36 AM Sebastian Huber > > > wrote: > > > > > > > > On 01/08/2022 10:28, Jo=C3=ABl Kr=C3=A4hemann wrote: > > > > > pthread_mutex_t mtx of struct test_context. > > > > > > > > > > You lock it in line 503 first, then you call test_timeout_finite(= ), > > > > > which calls event_post() in run() second lock. > > > > > > > > the event_post() and event_get() use their own data structures with > > > > dedicated mutexes and condition variables: > > > > > > > > typedef struct { > > > > int value; > > > > pthread_mutex_t mtx; > > > > pthread_cond_t cnd; > > > > } event; > > > > > > > > -- > > > > 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, = Thomas D=C3=B6rfler > > > > Unsere Datenschutzerkl=C3=A4rung finden Sie hier: > > > > https://embedded-brains.de/datenschutzerklaerung/