【发布时间】：2015-09-14 08:59:54
【问题描述】：
当递归调用 pthread_create() 时，我遇到了数据竞争。 我不知道递归是否会导致问题， 但比赛似乎从未在第一次迭代中发生，主要是在第二次迭代中，很少发生在第三次迭代中。
使用 libgc 时，会出现内存损坏症状，例如分段错误，这与数据竞争相吻合。
以下程序是说明问题的最小示例。 我没有在示例中使用 libgc，因为只有数据竞争才是这个问题的主题。
使用 Helgrind 工具运行 Valgrind 时可以看到数据竞争。 报告的问题略有不同，有时甚至完全没有问题。
我正在运行 Linux Mint 17.2。 gcc的版本是（Ubuntu 4.8.4-2ubuntu1~14.04）4.8.4。
以下示例“main.c”重现了该问题。它遍历一个链表，在一个单独的线程中打印每个元素的值：
#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>
typedef struct List {
int head ;
struct List* tail ;
} List ;
// create a list element with an integer head and a tail
List* new_list( int head, List* tail ) {
List* l = (List*)malloc( sizeof( List ) ) ;
l->head = head ;
l->tail = tail ;
return l ;
}
// create a thread and start it
void call( void* (*start_routine)( void* arg ), void* arg ) {
pthread_t* thread = (pthread_t*)malloc( sizeof( pthread_t ) ) ;
if ( pthread_create( thread, NULL, start_routine, arg ) ) {
exit( -1 ) ;
}
pthread_detach( *thread ) ;
return ;
}
void print_list( List* l ) ;
// start routine for thread
void* print_list_start_routine( void* arg ) {
// verify that the list is not empty ( = NULL )
// print its head
// print the rest of it in a new thread
if ( arg ) {
List* l = (List*)arg ;
printf( "%d\n", l->head ) ;
print_list( l->tail ) ;
}
return NULL ;
}
// print elements of a list with one thread for each element printed
// threads are created recursively
void print_list( List* l ) {
call( print_list_start_routine, (void*)l ) ;
}
int main( int argc, const char* argv[] ) {
List* l = new_list( 1, new_list( 2, new_list( 3, NULL ) ) ) ;
print_list( l ) ;
// wait for all threads to finnish
pthread_exit( NULL ) ;
return 0 ;
}
这里是'makefile'：
CC=gcc
a.out: main.o
$(CC) -pthread main.o
main.o: main.c
$(CC) -c -g -O0 -std=gnu99 -Wall main.c
clean:
rm *.o a.out
这是 Helgrind 最常见的输出。请注意，只有一个数字 1、2 和 3 的行是程序的输出，而不是 Helgrind：
$ valgrind --tool=helgrind ./a.out
==13438== Helgrind, a thread error detector
==13438== Copyright (C) 2007-2013, and GNU GPL'd, by OpenWorks LLP et al.
==13438== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==13438== Command: ./a.out
==13438==
1
2
==13438== ---Thread-Announcement------------------------------------------
==13438==
==13438== Thread #3 was created
==13438== at 0x515543E: clone (clone.S:74)
==13438== by 0x4E44199: do_clone.constprop.3 (createthread.c:75)
==13438== by 0x4E458BA: pthread_create@@GLIBC_2.2.5 (createthread.c:245)
==13438== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==13438== by 0x4007EB: call (main.c:25)
==13438== by 0x400871: print_list (main.c:58)
==13438== by 0x40084D: print_list_start_routine (main.c:48)
==13438== by 0x4C30E26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==13438== by 0x4E45181: start_thread (pthread_create.c:312)
==13438== by 0x515547C: clone (clone.S:111)
==13438==
==13438== ---Thread-Announcement------------------------------------------
==13438==
==13438== Thread #2 was created
==13438== at 0x515543E: clone (clone.S:74)
==13438== by 0x4E44199: do_clone.constprop.3 (createthread.c:75)
==13438== by 0x4E458BA: pthread_create@@GLIBC_2.2.5 (createthread.c:245)
==13438== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==13438== by 0x4007EB: call (main.c:25)
==13438== by 0x400871: print_list (main.c:58)
==13438== by 0x4008BB: main (main.c:66)
==13438==
==13438== ----------------------------------------------------------------
==13438==
==13438== Possible data race during write of size 1 at 0x602065F by thread #3
==13438== Locks held: none
==13438== at 0x4C368F5: mempcpy (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==13438== by 0x4012CD6: _dl_allocate_tls_init (dl-tls.c:436)
==13438== by 0x4E45715: pthread_create@@GLIBC_2.2.5 (allocatestack.c:252)
==13438== by 0x4C30C90: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==13438== by 0x4007EB: call (main.c:25)
==13438== by 0x400871: print_list (main.c:58)
==13438== by 0x40084D: print_list_start_routine (main.c:48)
==13438== by 0x4C30E26: ??? (in /usr/lib/valgrind/vgpreload_helgrind-amd64-linux.so)
==13438== by 0x4E45181: start_thread (pthread_create.c:312)
==13438== by 0x515547C: clone (clone.S:111)
==13438==
==13438== This conflicts with a previous read of size 1 by thread #2
==13438== Locks held: none
==13438== at 0x51C10B1: res_thread_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==13438== by 0x51C1061: __libc_thread_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==13438== by 0x4E45199: start_thread (pthread_create.c:329)
==13438== by 0x515547C: clone (clone.S:111)
==13438==
3
==13438==
==13438== For counts of detected and suppressed errors, rerun with: -v
==13438== Use --history-level=approx or =none to gain increased speed, at
==13438== the cost of reduced accuracy of conflicting-access information
==13438== ERROR SUMMARY: 8 errors from 1 contexts (suppressed: 56 from 48)
正如 Pooja Nilangekar 所述，将 pthread_detach() 替换为 pthread_join() 可以消除竞争。但是，分离线程是一项要求，因此目标是干净分离线程。换句话说，在移除比赛的同时保留 pthread_detach()。
线程之间似乎有一些意外的共享。 无意分享可能与此处讨论的内容有关：http://www.domaigne.com/blog/computing/joinable-and-detached-threads/ 尤其是示例中的错误。
我还是不明白到底发生了什么。
【问题讨论】：
-
您是否尝试将
-pthread添加到makefile 的编译规则中？ -
是的，但我删除了它。它没有效果。我认为只有链接阶段才有必要。