Thread: Probably very easy question about pthread mutexes

Since threads need to be joined, why do you need to keep track of which ones are running at all?

Code:

for (int i = 0; i < NTHREADS; ++i)
    thread[i] = pthread_create(...);

// Workers are running, wait for them to finish

for (int i = 0; i < NTHREADS; ++i)
    pthread_join(thread[i], NULL);

The second loop will only terminate when all the threads have terminated.

(Hint drop: Intel TBB. Use Google)

Originally Posted by synthetix

I only need a filename variable from the producer thread, so I tried unlocking each thread after they acquire the filename. This works well, but once the loop in the producer is complete, the program quits before waiting for the rest of the threads to complete. This happens because those threads freed their locks very early, after they got their filenames. The real number crunching takes a little time so of course the producer thread quits immediately, terminating the worker threads while they're in the middle of crunching.

To deal with this, should I call pthread_join() for as many worker threads exist?

Here:

Code:

for(i=0;i<num_threads;i++){
	pthread_join(threads[i],NULL);
}

return 0; //end of main

Actually, I just tried this, and it doesn't work since each thread is running an endless while() loop. Should I add a condition to the while()?

Originally Posted by synthetix

Thanks. I rewrote my program using CodePlug's example in post #10 in the link you posted. However, with that code it seems as though no two threads can ever concurrently process data because they lock the entire time they are working, which locks everything else until each thread is complete since everything is referencing the same mutex.

Hmmm -- did you understand condition_wait()? It unlocks the mutex.

However, you do have a point, because the concept of a queue is not in that example; the producer hands off a singular I/O task that must complete before it creates another one. But the example is just to demonstrate the function of the wait condition. Imagine moving the printf() outside the lock (by copying the locked data) and maybe you can see more the value of de-synchronizing these activities (rather than wait for each printf() to complete, you could move on and accumulate data asynchronously).

So, instead, use a FIFO structure (aka, a queue) contained by a first condition; when the producer is done with whatever provides it input, it waits on that to add until nothing is left. Tautology: the specifics of threading are a lot about the specifics of the task. In your case, it might be that the producer should just populate this queue (if the tasks are a finite list), then launch the threads detached (in which case, you do not need this first of two conditions, you only need the next one..).

After that, the detached worker threads all wait for the same condition -- that the queue can be accessed -- pull a task, and release the condition. Then they work on the task, outside of the locked state, hence, asynchronously.

I also don't understand the mutex in the producer thread. The lock is outside of the loop, and gets unlocked by the first thread that's spawned.

Nope. You are perhaps discussing mutex's and conditions as if they are synonymous, but they are not. Conditions depend upon and control mutexes.