2

AFAIK there are pthread functions that acts as memory barriers (e.g. here clarifications-on-full-memory-barriers-involved-by-pthread-mutexes). But what about compile-time barrier, i.e. is compiler (especially gcc) aware of this?
In other words - e.g. - is pthread_create() reason for gcc not to perform reordering?

For example in code:

a = 1;
pthread_create(...);

Is it certain that reordering will not take place?
What about invocations from different functions:

void fun(void) {
    pthread_create(...);
    ...
}

a = 1;
fun();

Is fun() also compile time barrier (assuming pthread_create() is)?
What about functions in different translation units?

Please note that I am interested in general gcc and pthreads behavior scpecification, not necessarily x86-specific (various different embedded platforms in focus).
I am also not interested in other compilers/thread libraries behavior.

Community
  • 1
  • 1
Andy
  • 1,036
  • 12
  • 14

1 Answers1

3

Because functions such as pthread_create() are external functions the compiler must ensure that any side effects that could be visible to an external function (such as a write to a global variable) must be done before calling the function. The compile couldn't reorder the write to a until after the function call in the first case) assuming a was global or otherwise potentially accessible externally).

This is behavior that is necessary for any C compiler, and really has little to do with threads.

However, if the variable a was a local variable, the compiler might be able to reorder it until after the function call (a might not even end up in memory at all for that matter), unless something like the address of a was taken and made available externally somehow (like passing it as the thread parameter).

For example:

int a;

void foo(void)
{
    a = 1;
    pthread_create(...);    // the compiler can't reorder the write to `a` past 
                            //  the call to `pthread_create()`

    // ...
}


void bar(void)
{
    int b;
    b = 1;
    pthread_create(...);    // `b` can be initialized after calling `pthread_create()`
                            // `b` might not ever even exist except as a something
                            //  passed on the stack or in a register to `printf()`

    printf( "%d\n", b);
}

I'm not sure if there's a document that outlines this in more detail - this is covered largely by C's 'as if' rule. In C99 that's in 5.1.2.3/3 "Program execution". C is specified by an abstract machine with sequence points where side effects must be complete, and programs must follow that abstract machine model except where the compiler can deduce that the side effects aren't needed.

In my foo() example above, the compiler would generally not be able to deduce that setting a = 1; isn't needed by pthread_create(), so the side effect of setting a to the value 1 must be completed before calling pthread_create(). Note that if there are compilers that perform global optimizations that can deduce that a isn't used elsewhere, they could delay or elide the assignment. However, in that case nothing else is using the side effect, so there would be no problem with that.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • Does it matter if variable has internal or external linkage (static vs extern)? – Andy Nov 24 '12 at 19:47
  • 1
    In principal variables with internal linkage could be treated similarly to locals. However, if they they become externally accessible even indirectly, then the compiler would have to treat them similarly to globals. For example, if the `static` variable is used by your thread function, then it's indirectly accessible externally since the thread function is called from 'outside' (this can be detected by the compiler because a pointer to the thread function is passed to an external function). – Michael Burr Nov 24 '12 at 20:08
  • I do not really get your last comment. IMHO static variable can be indirectly used by thread via other external functions (which gets pointer to static a before thread was created). But what I am looking for more, is formal description (e.g. link to gcc documentation, mailing list post) to rules when reordering can take place and when cannot. – Andy Nov 24 '12 at 20:23
  • @Andy: added a bit to the answer in response to your above comment. – Michael Burr Nov 25 '12 at 01:00