pthread_create timing of writeback

In the call pthread_create(&id, NULL, &start_routine, arg), is the thread id guaranteed to be written to id before start_routine starts running? The manpages are clear that the start_routine may but will not necessarily begin executing before the call to pthread_create returns, but they are silent on when the thread id gets written back to the passed thread argument.

My specific case is that I have a wrapper arou开发者_如何学编程nd pthread_create:

int mk_thread(pthread_t *id) {
  pthread_t tid;
  pthread_create(&tid,NULL,ThreadStart,NULL);
  if (id == NULL) {
    pthread_detach(tid);
  } else {
    *id=lid;
  }
}

which can obviously run the start routine before writing back. I changed it to

int mk_thread(pthread_t *id) {
  pthread_t tid,tidPtr=id?id:&tid;
  pthread_create(tidPtr,NULL,ThreadStart,NULL);
  if (id == NULL) {
     pthread_detach(tid);
  }
}

This rewrite is much more stable in practice, but is it actually a fix or just a smaller window for the race condition?

The thread id is definitely written before pthread_create returns. If you think about it, it would be impossible for pthread_create to work any other way. It could not delegate writing the thread id to the new thread, because the pthread_t variable might be out of scope by the time the new thread runs.

The relevant text is:

Upon successful completion, pthread_create() shall store the ID of the created thread in the location referenced by thread.

(From http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_create.html) Note that it says "on successful completion" of the function, not "at an indeterminate time after successful completion".

The more interesting question, and I'm unclear on this one, is whether pthread_create must have finished writing the thread id to its destination before the new thread start function begins, i.e. whether the new thread can immediately see its own thread id, e.g. if it's to be stored in a global variable. I suspect the answer is no.

Edit: Upon rereading your question, it seems like you might really have been asking about this latter, more interesting question. In any case, there's no reason for the new thread's start function to use the thread-id written out by pthread_create. Your new thread can (and should) just use pthread_self to get its own thread id.

I believe that nothing in the spec requires pthread_create to assign its output parameter pthread_t *thread before code in start_routine begins to execute.

As a matter of practicality, the following program succeeds on many pthreads implementations (freebsd8 i386 and debian gnu/linux amd64) but fails on one of interest to me (debian/kfreebsd9 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;
}

that said, I am not sure I understand how this detail of behavior is relevant to the two code alternatives you offer in the original question. Though it occurs to me that if pthread_create writes other values to *thread during its execution, and you're using the value of *id in the other thread, it could be relevant. The standard does not specify that no other 'intermediate' values are written to *thread during successful execution of pthread_create.