Thread synchronization - Functions

[mrdave2]

Ok, I know you have to synchronize access to variables that are shared between threads, but what about functions? Say, some sort of parse function that does not access any shared variables, would I need to synchronize access to that function too?

This could be a problem too if I need to do that, because to save myself from alot of tedious coding, I wrote functions to call Enter/LeaveCriticalSection for alot of objects I use between threads. So far, I have not had any crashes or anything of the sort related to this, but it would be helpful to know so I can go over my code now and add the proper handling for them.

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?

Thanks!

[Marc G]

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.

[Andreas Masur]

[ Merged threads ]

[Andreas Masur]

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...

[mrdave2]

Well...if there is only reading access....then there isn't a need for synchronization...

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.

[MikeAThon]

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

[MrViggy]

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

[Andreas Masur]

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...

[Andreas Masur]

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.

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...

[Arjay]

...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

[MikeAThon]

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"

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

[Andreas Masur]

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...

[Andreas Masur]

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...

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....

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...