[Pkg-phototools-devel] Bug#696644: I think darktable assumes something pthreads does not guarantee

[Jeff Epler]

Control: tags -1 + upstream

... but I'm not sure.

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