public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
* Problems with conditions
@ 2021-03-29 12:19 markus.forrer
  2021-03-30  7:15 ` Ger Hobbelt
  0 siblings, 1 reply; 5+ messages in thread
From: markus.forrer @ 2021-03-29 12:19 UTC (permalink / raw)
  To: pthreads-win32

I have re-implemented the C++ class OSEvent for a Windows simulation that exists for a Linux platform. Thereby I have the problem that the function pthread_cond_wait() does not wait until pthread_cond_signal() is called. Something I have misunderstood.

Many thanks for any hints!


OSEvent::OSEvent()
{
    pthread_condattr_init(&_conditionAttribute);
    pthread_cond_init(&_condition, &_conditionAttribute);
    pthread_mutexattr_init(&_mutexAttribute);
    pthread_mutexattr_settype(&_mutexAttribute, PTHREAD_MUTEX_ERRORCHECK);
    pthread_mutex_init(&_mutex, &_mutexAttribute);
}

OSEvent::~OSEvent()
{
    pthread_cond_destroy(&_condition);
    pthread_condattr_destroy(&_conditionAttribute);
    pthread_mutex_destroy(&_mutex);
    pthread_mutexattr_destroy(&_mutexAttribute);
}

void OSEvent::signal()
{
    pthread_mutex_lock(&_mutex);
    pthread_cond_signal(&_condition);
    pthread_mutex_unlock(&_mutex);
}

OSEventError OSEvent::timedwait(uint32_t timeout)
{
    struct timespec timeoutTime;
    timeoutTime.tv_sec = timeout / 1000;
    timeoutTime.tv_nsec = 1000000 * (timeout % 1000);
    OSEventError success = OSEventError::NoError;
    pthread_mutex_lock(&_mutex);

    // Timeout forever
    if (timeout == 0)
    {
        if (pthread_cond_wait(&_condition, &_mutex) != 0)
        {
            success = OSEventError::Timeout;
        }
    }

    // Timeout time
    else
    {
        if (pthread_cond_timedwait(&_condition, &_mutex, &timeoutTime) != 0)
        {
            success = OSEventError::Timeout;
        }
    }

    pthread_mutex_unlock(&_mutex);
    return success;
}


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Problems with conditions
  2021-03-29 12:19 Problems with conditions markus.forrer
@ 2021-03-30  7:15 ` Ger Hobbelt
  2021-03-30 15:37   ` Aw: " markus.forrer
  0 siblings, 1 reply; 5+ messages in thread
From: Ger Hobbelt @ 2021-03-30  7:15 UTC (permalink / raw)
  To: markus.forrer; +Cc: pthreads-win32

See
https://stackoverflow.com/questions/16522858/understanding-of-pthread-cond-wait-and-pthread-cond-signal/16524148,
also read ALL comments there as some details get explained further.

Compare your mutex lock.. Unlock code with the sample code in the answer
there: your code has "nothing to do that requires..." so do not need to
wait.

On Mon, Mar 29, 2021, 14:20 Markus Forrer via Pthreads-win32 <
pthreads-win32@sourceware.org> wrote:

> I have re-implemented the C++ class OSEvent for a Windows simulation that
> exists for a Linux platform. Thereby I have the problem that the function
> pthread_cond_wait() does not wait until pthread_cond_signal() is called.
> Something I have misunderstood.
>
> Many thanks for any hints!
>
>
> OSEvent::OSEvent()
> {
>     pthread_condattr_init(&_conditionAttribute);
>     pthread_cond_init(&_condition, &_conditionAttribute);
>     pthread_mutexattr_init(&_mutexAttribute);
>     pthread_mutexattr_settype(&_mutexAttribute, PTHREAD_MUTEX_ERRORCHECK);
>     pthread_mutex_init(&_mutex, &_mutexAttribute);
> }
>
> OSEvent::~OSEvent()
> {
>     pthread_cond_destroy(&_condition);
>     pthread_condattr_destroy(&_conditionAttribute);
>     pthread_mutex_destroy(&_mutex);
>     pthread_mutexattr_destroy(&_mutexAttribute);
> }
>
> void OSEvent::signal()
> {
>     pthread_mutex_lock(&_mutex);
>     pthread_cond_signal(&_condition);
>     pthread_mutex_unlock(&_mutex);
> }
>
> OSEventError OSEvent::timedwait(uint32_t timeout)
> {
>     struct timespec timeoutTime;
>     timeoutTime.tv_sec = timeout / 1000;
>     timeoutTime.tv_nsec = 1000000 * (timeout % 1000);
>     OSEventError success = OSEventError::NoError;
>     pthread_mutex_lock(&_mutex);
>
>     // Timeout forever
>     if (timeout == 0)
>     {
>         if (pthread_cond_wait(&_condition, &_mutex) != 0)
>         {
>             success = OSEventError::Timeout;
>         }
>     }
>
>     // Timeout time
>     else
>     {
>         if (pthread_cond_timedwait(&_condition, &_mutex, &timeoutTime) !=
> 0)
>         {
>             success = OSEventError::Timeout;
>         }
>     }
>
>     pthread_mutex_unlock(&_mutex);
>     return success;
> }
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Aw: Re: Problems with conditions
  2021-03-30  7:15 ` Ger Hobbelt
@ 2021-03-30 15:37   ` markus.forrer
  2021-03-31  1:30     ` ross.johnson
  0 siblings, 1 reply; 5+ messages in thread
From: markus.forrer @ 2021-03-30 15:37 UTC (permalink / raw)
  To: Ger Hobbelt; +Cc: pthreads-win32

Thank you for your answer.

The main problem was the line:

pthread_mutexattr_settype(&_mutexAttribute, PTHREAD_MUTEX_ERRORCHECK);
 
After changing to PTHREAD_MUTEX_DEFAULT it works.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Aw: Re: Problems with conditions
  2021-03-30 15:37   ` Aw: " markus.forrer
@ 2021-03-31  1:30     ` ross.johnson
  2021-03-31  4:43       ` Markus Forrer
  0 siblings, 1 reply; 5+ messages in thread
From: ross.johnson @ 2021-03-31  1:30 UTC (permalink / raw)
  To: markus.forrer, Ger Hobbelt; +Cc: pthreads-win32

That should not make any difference (unless there's a bug in the pthreads implementation). In pthreads-win32 the ERRORCHECK CV uses the ERRORCHECK mutex which adds checks to ensure the unlocking thread owns the mutex lock. (ERRORCHECK isn't meant to be used in production code btw). That it does make a difference, ie your code now works, suggests there is a dependency on timing between the threads that you need to have control of.The code that you included in your first email never sets the condition variable itself before signaling and does not check the condition variable after waking. The example shown in the link that Ger provided does both and that is the way condition variables are intended to be used. Note the example uses a while loop to check the condition variable before entering the wait and then again after waking and before unlocking the mutex. If the condition isn't true after waking the CV should go back into the wait. Google search for "condition variable spurious wakeup".Sent from my phone
-------- Original message --------From: Markus Forrer via Pthreads-win32 <pthreads-win32@sourceware.org> Date: 31/3/21  2:37 am  (GMT+10:00) To: Ger Hobbelt <ger@hobbelt.com> Cc: pthreads-win32@sourceware.org Subject: Aw: Re: Problems with conditions Thank you for your answer.The main problem was the line:pthread_mutexattr_settype(&_mutexAttribute, PTHREAD_MUTEX_ERRORCHECK); After changing to PTHREAD_MUTEX_DEFAULT it works.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: RE:  Re: Problems with conditions
  2021-03-31  1:30     ` ross.johnson
@ 2021-03-31  4:43       ` Markus Forrer
  0 siblings, 0 replies; 5+ messages in thread
From: Markus Forrer @ 2021-03-31  4:43 UTC (permalink / raw)
  To: ross.johnson; +Cc: Ger Hobbelt, pthreads-win32

Thank you for your answer.

I implemented the code exactly the same way (with the condition variable) as in the sample code. But it worked only after I replaced PTHREAD_MUTEX_ERRORCHECK with PTHREAD_MUTEX_DEFAULT. The main thing is that it works now! :-)


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-03-31  4:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-29 12:19 Problems with conditions markus.forrer
2021-03-30  7:15 ` Ger Hobbelt
2021-03-30 15:37   ` Aw: " markus.forrer
2021-03-31  1:30     ` ross.johnson
2021-03-31  4:43       ` Markus Forrer

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).