Re: Thread synchronization
Quote:
Originally Posted by mrdave2
Say, some sort of parse function that does not access any shared variables, would I need to synchronize access to that function too?
No you don't.
Re: Thread synchronization
Re: Thread synchronization
Quote:
Originally Posted by mrdave2
Also, would I need to synchronize access to variables if im only reading the variable's data in the threads and not changing their value?
Well...if there is only reading access....then there isn't a need for synchronization...
Re: Thread synchronization
Quote:
Originally Posted by Andreas Masur
Well...if there is only reading access....then there isn't a need for synchronization...
:o
So let me get this straight, I can have multiple threads reading global variables simotaneously without synchronizing access? I was always under the impression you needed to synchronize access if you read or changed the variable.
Re: Thread synchronization
Quote:
Originally Posted by Andreas Masur
Well...if there is only reading access....then there isn't a need for synchronization...
Although this might be true in the case of PODs, I don't think it's true in general.
For PODs like char and int, then so long as the variable's length does not exceed the native width of the processor (e.g., a 32 bit long on a Pentium 32 bit processor), then much has been written that such accesses are atomic. Since the access is atomic, then it's probably true that synchronization isn't really needed.
But beyond PODs, synchronization is essential. If you define your own data structure, then it is essential to protect even read-only access to an object of that structure with a synchronization object.
And in the end, isn't it easier simply to use synchronization objects always, as a precaution? (For example, a precaution that in some future release, your formerly POD variable is changed into a multi-part structure)
Mike
Re: Thread synchronization - Functions
You need to synchronize if there's a possibility that a value could change while you are reading it. In other words, if you are constantly reading and writing a value, from different threads, then you will need to synchronize.
If you have one thread that initializes a bunch of values; then kicks off a bunch of threads that only read those values, then there is no need to synchronize access to the values.
Viggy
Re: Thread synchronization
Quote:
Originally Posted by mrdave2
I was always under the impression you needed to synchronize access if you read or changed the variable.
Well...there is a difference whether variables are only being read or being changed as well. In the latter case, synchronization is definitely necessary to guarantee data consistency, however, in the former case the data won't change thus, consistency isn't a problem...
Re: Thread synchronization
Quote:
Originally Posted by MikeAThon
But beyond PODs, synchronization is essential. If you define your own data structure, then it is essential to protect even read-only access to an object of that structure with a synchronization object.
Why would it? Why would it matter whether the operation is atomic or not given the fact that the data isn't going to change. Thus, even if one thread gets interrupted while reading the value, it is still guaranteed that the value is till the same when it got again CPU time and read further.
Quote:
Originally Posted by MikeAThon
And in the end, isn't it easier simply to use synchronization objects always, as a precaution? (For example, a precaution that in some future release, your formerly POD variable is changed into a multi-part structure)
As I said...it has nothing to do with PODs in the first place...besides that, synchronization is something that you buy at a high cost...in CPU cycles...thus, if you have something that is guaranteed to be read-only...you can increase the performance of your application by simply skipping the (unnecessary) synchronization...
Re: Thread synchronization
Quote:
Originally Posted by Andreas Masur
...thus, if you have something that is guaranteed to be read-only...you can increase the performance of your application by simply skipping the (unnecessary) synchronization...
Unfortunately, code has a habit of changing and what was intended to be absolutely read-only by the original programmer may not be the case when someone else takes over the code. For me, guarding access is worth the slight performance hit to ensure I don't run into a random, hard to find issue. I figure if I don't protect the access, I would have to comment the heck out of the code - I like comments, but not that much. :)
Arjay
Re: Thread synchronization
Quote:
Originally Posted by Andreas Masur
Why would it? Why would it matter whether the operation is atomic or not given the fact that the data isn't going to change. Thus, even if one thread gets interrupted while reading the value, it is still guaranteed that the value is till the same when it got again CPU time and read further.
That's not the way I interpreted the OP's question. As I understood it, the reading thread might not change the value of the data, but there will be some other thread out there that might. After all, and putting aside const's for a bit, what's the purpose of defining a variable that never changes; is it even fair to call it a "variable" :rolleyes:
Anyway, if the data can be changed by another thread (or thread in another process; e.g. com), then I think a reading thread, even if it's a read-only operation, should surround the read with a synchronization object. Otherwise, and contrary to your post, there's a real chance that after an interupted thread gets CPU time, the value will not be the same as before the interruption.
Mike
Re: Thread synchronization
Quote:
Originally Posted by Arjay
Unfortunately, code has a habit of changing and what was intended to be absolutely read-only by the original programmer may not be the case when someone else takes over the code. For me, guarding access is worth the slight performance hit to ensure I don't run into a random, hard to find issue. I figure if I don't protect the access, I would have to comment the heck out of the code - I like comments, but not that much. :)
Well...my standpoint on this is simply that the one who changes the code later and introduces write access to a shared object should take precautions of synchronization....in other words, if I later add write access, I am responsible for the proper synchronization as well....I simply do not want to add code for every potential change that might come in the future in my code...
However, this is only my personal preference... ;)
Re: Thread synchronization
Quote:
Originally Posted by MikeAThon
That's not the way I interpreted the OP's question. As I understood it, the reading thread might not change the value of the data, but there will be some other thread out there that might.
Well...
Quote:
Also, would I need to synchronize access to variables if im only reading the variable's data in the threads and not changing their value?
was everything I based my answer on....
Quote:
Originally Posted by MikeAThon
Anyway, if the data can be changed by another thread (or thread in another process; e.g. com), then I think a reading thread, even if it's a read-only operation, should surround the read with a synchronization object. Otherwise, and contrary to your post, there's a real chance that after an interupted thread gets CPU time, the value will not be the same as before the interruption.
That is a different scenario as I have posted in reply #8. If the shared objects has read/write access then it has to be properly synchronized...
