https://bugs.kde.org/show_bug.cgi?id=502871

            Bug ID: 502871
           Summary: Make Helgrind  "pthread_cond_{signal,broadcast}:
                    dubious: associated lock is not held by any thread"
                    optional
    Classification: Developer tools
           Product: valgrind
           Version: 3.25 GIT
          Platform: Compiled Sources
                OS: Unspecified
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: helgrind
          Assignee: jsew...@acm.org
          Reporter: pjfl...@wanadoo.fr
  Target Milestone: ---

On Illumos and Solaris I want to make this optional and off by default.

The Illumos man page for pthread_cond_broadcast says

       The pthread_cond_signal() or pthread_cond_broadcast() functions may be
       called by a thread whether or not it currently owns the mutex that
       threads calling pthread_cond_wait() or pthread_cond_timedwait() have
       associated with the condition variable during their waits; however, if
       predictable scheduling behavior is required, then that mutex is locked
       by the thread calling pthread_cond_signal() or
       pthread_cond_broadcast().

Here is the Illumos implementation of pthread_barrier_wait:

int
pthread_barrier_wait(pthread_barrier_t *barrier)
{
        mutex_t *mp = (mutex_t *)&barrier->__pthread_barrier_lock;
        cond_t *cvp = (cond_t *)&barrier->__pthread_barrier_cond;
        uint64_t cycle;
        int cancel_state;

        (void) mutex_lock(mp);

        if (--barrier->__pthread_barrier_current == 0) {
                barrier->__pthread_barrier_cycle++;
                barrier->__pthread_barrier_current =
                    barrier->__pthread_barrier_count;
                (void) mutex_unlock(mp);
                (void) cond_broadcast(cvp);
                return (PTHREAD_BARRIER_SERIAL_THREAD);
        }

        (void) pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cancel_state);
        cycle = barrier->__pthread_barrier_cycle;
        do {
                (void) cond_wait(cvp, mp);
        } while (cycle == barrier->__pthread_barrier_cycle);
        (void) pthread_setcancelstate(cancel_state, NULL);

        (void) mutex_unlock(mp);
        return (0);
}

The key thing there is
                (void) mutex_unlock(mp);
                (void) cond_broadcast(cvp);

That means that there is a "dubious associated lock" error every time that
pthread_barrier_wait fires due to the barrier count reaching zero.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to