Hello. I was reading a lot about the volatile keyword lately in the net and the oppinions are very contradicting.
I am using pthreads. I know that I am supposed to use mutexes to avoid problems with the shared variables, but sometimes it's just redicolous to use a mutex.
First of all I don't know how one's supposed to stop a running thread. I've researched ptherad_cancel, but it doesn't work for me, because when I stop the tread I must be able to cleanup and do some stuff. I currently have a shared flag "stop" that acts to tell a thread to stop. There's a loop in the tread that executes while !stop. So this flag is checked every iteration. It seems to me that It would be very funny to protect a single flag that must be only read and is almost always going to be false (false is 0, it's defined in the standart library <stdbool.h>). It works fine, but after reading a lot of things about multithreading programming I descovered that's not very correct, because the flag may be cached and never be read. So I discovered the volatile word that seemed to be a correct way to do it, but then I came to all sorts of articles in the net against the use of volatile in multithreading. For this case it seems that volatile will be correct for me, because articles show problems with volatile that don't concern me in this situation:
1. processor can rearange instructions - I don't care about that, the only thing I care is this variable to be read correctly some time after setting it to true
2. the volatile doesn't mean atomic - well ... for a flag it's obvious that it's not a problem
So I think as much as volatile is usless in multithreading programming I think in this case it should work better then accuiring and releasing a mutex every iteration.
If there's a standart way to stop a thread different from using a shared flag, please tell me
The second thing is a ring buffer. There is one thread that writes in the buffer and many threads that read the buffer. The write thread keeps a pointer that I use by the other threads as the marker where the reading should end. When the writing thread writes a data it moves the pointer. The reading threads just follow that pointer reading the bytes on the way. A situation where the writing passes the reading won't happen in the normal circumstances and if it happens I expect that the reading thread that's been overtaken will miss one buffer length of data (which is acceptable in an abnormal situation when the reader doesn't read fast enough). So I thought about protecting the buffer and the write pointer with a mutex, but I don't want to hurt the performance, because the reading threads can be many and accuiring a mutex every time before read is a thing that I want to avoid. Here I want to say again that in my machine everything works without volatile or mutexes but I'm afraid that on some unknown machine with multiple processors there may be some problems. So will there be problems for me to just declare the buffer and the write pointer as volatile if I make the following assumations:
1) pointer assignment is an atomic operation: I think that I won't come accross a machine in which the pointer assignment won't be atomic.
2) reading won't come close to beeing passed by the writing in normal circumstances and in case that happense there will at most be reading of currupt buffer data once and missing one length of the buffer (not program crash or something like that)
The thing I also want is to be sure that the write pointer will be moved AFTER the data is written in the buffer and that's the thing that I see nothing can help except mutexes. I want to avoid accuiring and releasing mutexex at every read at all cost.
I hope someone will be able to help the buffer situation. The thread stopping is mostly curiosity about volatile and common ways to stop a thread.
Thanks.
