While omp_thread_num is maintained for a full iteration, the same underlying thread won't necessarily perform the execution.
This made me wonder how omp deals non omp thread locals, i.e. __thread int; or errno, which are thread local to the underlying thread.
I can't find the information in the doc, but it seems like
#pragma omp parallel for
for (int i = 0; i < 10000; ++i) {
// exec by omp thread 1, using underlying thread a
fileptr = fopen(filenames[i], "rb");
variable_heavy_op(); // or just yield, or nothing,
// exec by omp thread 1, using underlying thread b,
if (!fileptr) // local to omp thread 1
perror(filename[i]); // // uses errno, local to underlying thread b,
}
would risk a really painful to debug rare threading error.
errno is a catastrophic design choice, I know, but some crap is difficult to avoid. Another example would be reading the result of a try lock operation in pthreads, or using omp with any non omp threading primitives or derived libraries like the standard template library.
The question is, is my assertion correct. Or simplified. If i create a __thread variable ( non omp thread bound variable) how does that interact with the omp threadpool?
Openmp does not guarantee that one omp thread corresponds to one system/os thread, but it does on linux.(pthread)
openmp does not guarantee that one os thread performs an entire operation, but it should on linux as a consequence of the os openmp 2 os thread correspondence. ( This contradicts my previous assertion in the question).
__thread corresponds to threadprivate on linux for gcc, but not for icc, though there is a compat flag. The clang openmp is based on the intel one, but its unclear how it behaves, lack of warning on tests indicate it works like gcc or lacks the warning intel would give. Works like gcc seems likely.
To answer the question directly errno works on linux with gcc if its implemented as thread local, but as homer points out its likely that someone fixed it for common configurations like linux + ICC.