pthread_create的参数在C ++中使用—每次线程函数获取值都相同，为什么？

Question

I used pthread_create in C++, and the program runs, but in pthread function, the argument result was the same. Why? I have used pthread_mutex_lock, but it is not effective. I can't find out the reason.

The codes below:

Minimal:

const int MAX_THREADS = 5;
class FileCpThread
{
public:
FileCpThread(const string &src,const string & des){
srcFile = src.c_str();
desFile = des.c_str();
}
~FileCpThread(){}
startThreadCopy();

private:
static void *threadCp(void *param);
static int getFileSize(const std::string &filename);
string srcFile;
int num;
string desFile;
};

Complete:

bool FileCpThread::startThreadCopy()
{

pthread_t pid[MAX_THREADS];

pthread_mutex_init(&mutex, NULL);

for (int i = 0; i < MAX_THREADS; i++)
{
pthread_mutex_lock(&mutex);
this->num = i;
pthread_mutex_unlock(&mutex);
pthread_create(&pid[i], NULL, threadCp, (void *)this);
}

for (int j = 0; j < MAX_THREADS; j++)
{
pthread_join(pid[j], NULL);
}

return true;
}
int FileCpThread::getFileSize(const string &filename)
{
struct stat st;
memset(&st, 0, sizeof(st));
stat(filename.c_str(), &st);
return st.st_size;
}

void *FileCpThread::threadCp(void *param)
{
FileCpThread *ft = (FileCpThread *)param;
FILE *fin = fopen(ft->srcFile.c_str(), "r+");
FILE *fout = fopen(ft->desFile.c_str(), "w+");

int size = getFileSize(ft->srcFile.c_str());
pthread_mutex_lock(&ft->mutex);
int number =  ft->num;
pthread_mutex_unlock(&ft->mutex);
cout << "number:::" << number << endl;

fseek(fin, size * (number) / MAX_THREADS, SEEK_SET);
fseek(fout, size * (number) / MAX_THREADS, SEEK_SET);

char buff[1024] = {'\0'};
int len = 0;
int total = 0;
while ((len = fread(buff, 1, sizeof(buff), fin)) > 0)
{
fwrite(buff, 1, len, fout);
total += len;

if (total > size / MAX_THREADS)
{
  break;
}
}

fclose(fin);
fclose(fout);
}

Verifiable:

bool FileCpThread::startThreadCopy()

pthread_mutex_lock(&ft->mutex);
int number =  ft->num;
pthread_mutex_unlock(&ft->mutex);
cout << "number:::" << number << endl;

Answer 1

You get the same value in the thread function because you pass the same value to it each time. Your code is:

for (int i = 0; i < MAX_THREADS; i++)
{
    pthread_mutex_lock(&mutex);
    this->num = i;
    pthread_mutex_unlock(&mutex);
    pthread_create(&pid[i], NULL, threadCp, (void *)this);
}

The value of this does not change between iterations, so the same value is passed to threadCp each time it is used.

If your problem is that all the threads see the same value for this->num , then the problem is still that you pass the same pointer to the function each time, but you also have the indeterminacy with which the threads are scheduled, and Sod's Law dictates that the threads won't be activated until the last one is created, so they all see the same value in this->num . You have to make sure that each thread gets independent information to work with — assuming each thread should be getting independent information.

---

For N threads, you need to create an array of N values — it appears that N int might be sufficient, and (a) set the elements appropriately and (b) pass one element of the array to each thread.

As an element of the class:

int thread_number[MAX_THREADS];

As initialization:

for (int i = 0; i < MAX_THREADS; i++)
    this->thread_number[i] = i;

In the call to pthread_create() :

pthread_create(&pid[i], NULL, threadCp, &this->thread_number[i]);

In the function threadCp() , instead of:

 FileCpThread *ft = (FileCpThread *)param; 

use:

int number = *(int *)param;

And you don't need the mutex for synchronization any more (at least, not to control access to the thread number).

If the number of threads is variable, use a vector<int> . If it would be more sensible to compute the split of the file before launching the threads, do that (it probably is sensible).

Do note that having 5 threads accessing separate portions of a single file is probably not going to improve overall performance. As an exercise in coordination between processes, it is fine. As an exercise in improving overall performance, it is probably not a good idea. (Reason: the file will be on a single file system, so the same controllers will be used in accessing the separate sections of disk, leading to head positioning contention. Performance might actually be worse than running single-threaded.)