Re: pthread_mutex_timedlock() vs. clock_settime()

["Joël Krähemann" <jkraehemann@gmail.com>]

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

On Mon, Aug 1, 2022 at 1:59 PM Joël Krähemann <jkraehemann@gmail.com> wrote:
>
> Hi,
>
> I co authored an article, check the section about working with parallelism:
>
> https://opensource.com/article/21/11/community-code-stories
>
> regards,
> Joël
>
> On Mon, Aug 1, 2022 at 1:51 PM Joël Krähemann <jkraehemann@gmail.com> 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=393da4d9fdc6c50ef3ab8eab27b562c85bd57664#n2002
> >
> > Or check this for condition:
> >
> > ~~~~
> >
> > volatile int is_wait;
> > volatile int is_done;
> >
> > static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER:
> > static pthread_cond_t cond = 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ël
> >
> > On Mon, Aug 1, 2022 at 11:51 AM Joël Krähemann <jkraehemann@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > Sorry, you are right. Might be your conditional lock is buggy. I think
> > > 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ël
> > >
> > >
> > > On Mon, Aug 1, 2022 at 10:36 AM Sebastian Huber
> > > <sebastian.huber@embedded-brains.de> wrote:
> > > >
> > > > On 01/08/2022 10:28, Joël Krähemann 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ünchen
> > > > Registernummer: HRB 157899
> > > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > > > Unsere Datenschutzerklärung finden Sie hier:
> > > > https://embedded-brains.de/datenschutzerklaerung/