I have a chunk of memory (bunch of arrays) that's protected by a simple mutex X.
Threads A and B will read and write into that memory.
Periodically, thread C will need to lock that mutex X, and attempt to write the arrays to disk.
This is all fine and good, except I would like C to spawn threads H, I, and J, each to write an array to disk. C will join on H, I, and J and unlock mutex X upon completion of all 3 disk writes (really more like 50 in my program: I will spawn 50 threads, one for each array, for simplicity).
Here is my question: can H, I, and J independently write the arrays to disk while C has a lock on mutex X? Will H, I, and J also have the lock on X since I call pthread_create() after acquiring mutex X? I think the answer is yes, and since H, I, and J are playing with different arrays, I don't have to worry about additional mutexes.
Given my requirements, can you think of a better threading design pattern?
This is all fine and good, except I would like C to spawn threads H, I, and J, each to write an array to disk. C will join on H, I, and J and unlock mutex X ... for simplicity.
Yes, believe it or not, spawning a bunch of threads without the need for synchronization is actually quite straightforward.
My testing also seems to indicate that the extra work is worth it:
Serial Threaded
------------------------------
real 0m4.041s 0m2.098s
user 0m1.861s 0m1.143s
sys 0m0.685s 0m0.507s
That's a 48% cut in real time (4.041s down to 2.098s), which is nice for a real-time app.
Hardware: 2.2GHz Dual-Core AMD 8GB 64-bit Ubuntu box.
Task: 192 ASCII files of various sizes to flush to disk at one minute intervals.
Serial: For-loop and write out 192 files, one-by-one in sequence.
Threaded: Spawn 192 pthreads, one for each file, and join() on the threads.
Maybe I should test a thread pool or try some fine-tuning of number of threads, before inserting this into the code base.
Edit: Reran test over 10 times to get a more realistic result; reposted numbers