I am trying to use mutexes to avoid multiple writes to the same thread inC/Cpp. Below is the flow of my program. I am confused as to where to include my lock and unlock code.
main() {
spawn a worker thread
}
worker_thread() {
read the input file name
read some content
write the content to the given file name
}
Most of the implementation that I see, seem to have something like this:
main() {
pthread_mutex_init(&myMutex;,0);
*spawn a worker thread*
pthread_join(thread1, 0);
pthread_mutex_destroy(&myMutex;);
}
worker_thread() {
read the input file name
read some content
write the content to the given file name
}
What I want it something like this:
main() {
spawn a worker thread
}
worker_thread() {
read the input file name
read some content
pthread_mutex_init(&myMutex;,0) --> for the given file?
write the content to the given file name
pthread_mutex_destroy(&myMutex;);
}
Any ideas to proceed much appreciated. Thank you!
It's fairly easy to create a wrapper for an iostream that ensures only one thread can write to the stream at a time. Unfortunately, almost as soon as you do so, you run into another problem. It ensures that only one thread can insert into the stream at a time, so you get defined behavior. If, however, you have something like:
thread 1:
sync_stream << a << b << c << '\n';
thread 2:
sync_stream << x << y << z << '\n';
What you wanted was either:
...or else:
Since they're in separate threads, it's fine for the order between them to vary, but a line of output from one thread should remain a single line of output. Something like:
...probably isn't desired or acceptable. To ensure against this, we really need two separate classes. One is a synchronized stream. The other is something to let us do some (more or less arbitrary) set of insertions into the stream as a single, indivisible "transaction". To do that, we can use a pair of classes like this:
Note that the
transaction
class supports chaining, but thesync_stream
does not (and the only thing you can insert into it is atransaction
). To use them, we do something like this:This way, what a thread thinks of as a single output actually comes out as a single output, so our result might look like this:
Of course, you'll get different thread IDs than I did, and the order of the lines is likely to vary--but each line will be written as a single, intact unit.
Summary
The worker threads shouldn't work directly with the mutex at all. That should be automated, so the worker thread can focus on its work, and spend only a bare minimum of effort on the underlying mechanism necessary for it to do its job.