Project

General

Profile

Bug #9197

Possible pthread misuse

Added by bremner - over 6 years ago.

Status:
New
Priority:
Medium
Assignee:
-
Category:
-
Target version:
-
Start date:
01/25/2013
Due date:
% Done:

0%

Affected Version:
1.1.1
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

It has been reported that darktable fails to start about 50% of the time on Debian/KFreeBSD

The full story is at

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696644

In particular

in http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=696644, Jeff Epler writes:

Basically, it appears that there's a race between setting a value in the
main thread and reading it in another thread. The value is
darktable.control->thread_res[threadid]. It's accessed in the created
thread in dt_control_get_threadid_res and is set in the main thread by
pthread_create() via the pthread_t* argument.

I boiled the problem down to the following program, which succeeds
invariably on Debian GNU/Linux amd64 but fails with regularity on Debian
GNU/kfreebsd amd64:

    #include <pthread.h>
    #include <assert.h>
    #include <stdint.h>
    #include <stdio.h>

    pthread_t th;

    void *asserter(void* unused) {
        pthread_t self = pthread_self(), th_=th;
        printf("th=%jd self=%jd\n", (intmax_t)th_, (intmax_t)self);
        assert(pthread_equal(th_, self));
    }

    int main() {
        int i;
        for(i=0; i<1000; i++) {
            pthread_create(&th, NULL, asserter, NULL);
            pthread_join(th, NULL);
        }
        return 0;
    }

this is analagous to what darktable is doing in control.c:
/// like asserter()
770 while(!pthread_equal(darktable.control->thread_res[threadid],pthread_self()) && threadid < DT_CTL_WORKER_RESERVED-1)
771     threadid++;
772 assert(pthread_equal(darktable.control->thread_res[threadid], pthread_self()));

/// like main()
361 pthread_create(&s->thread_res[k], NULL, dt_control_work_res, s);

however, because more takes place in the child thread between
dt_control_work_res and the access of darktable.control->thread_res[threadid]
the failure is less frequent in darktable than in my sample program.

Because the specification of pthread_create does not explicltly say that
the assignment to its 'pthread_t *thread' output parameter occurs before
the thread's start_routine is called, I believe darktable is asking from
pthreads something it has no right to expect.

Jeff

Also available in: Atom PDF