public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: "Joël Krähemann" <jkraehemann@gmail.com>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>
Cc: libc-help@sourceware.org
Subject: Re: pthread_mutex_timedlock() vs. clock_settime()
Date: Tue, 2 Aug 2022 00:05:07 +0200	[thread overview]
Message-ID: <CA+Owze5_zY9EmJTg5cOqtdhrtKZDA=uNRVPRz71Qg_MdNyPVMQ@mail.gmail.com> (raw)
In-Reply-To: <CA+Owze6g9CE7Ltt9rrKv8dCapvMm4bF0diTdP=5L45aA8zUUWA@mail.gmail.com>

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ël

On Mon, Aug 1, 2022 at 10:11 PM Joël Krähemann <jkraehemann@gmail.com> 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_thread.c?h=4.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ël
>
> On Mon, Aug 1, 2022 at 6:31 PM Sebastian Huber
> <sebastian.huber@embedded-brains.de> wrote:
> >
> > Hello Joël,
> >
> > 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 on
> > 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ünchen
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/

      reply	other threads:[~2022-08-01 22:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02  8:43 Sebastian Huber
2022-08-01  7:10 ` Joël Krähemann
2022-08-01  7:41   ` Joël Krähemann
2022-08-03 23:44   ` Sebastian Huber
2022-08-01  8:28     ` Joël Krähemann
2022-08-01  8:36       ` Sebastian Huber
2022-08-01  9:51         ` Joël Krähemann
2022-08-01 11:51           ` Joël Krähemann
2022-08-01 11:59             ` Joël Krähemann
2022-08-01 14:44               ` Joël Krähemann
2022-08-01 16:31             ` Sebastian Huber
2022-08-01 20:11               ` Joël Krähemann
2022-08-01 22:05                 ` Joël Krähemann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+Owze5_zY9EmJTg5cOqtdhrtKZDA=uNRVPRz71Qg_MdNyPVMQ@mail.gmail.com' \
    --to=jkraehemann@gmail.com \
    --cc=libc-help@sourceware.org \
    --cc=sebastian.huber@embedded-brains.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).