Multithread- update and read the same value

I have an application that has multiple threads.(I am using WINAPI,process.h) Only one thread is updating the common data and the other threads are just reading. It is not important if the reader threads are reading the most up-to-date data.

Now my question is, do i need to put a lock mechanism for each of the reader threads ?


Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Hi parabellum,

yes, you somehow have to synchronize read-access too since if the writing thread tries to change the variable just in the moment another thread tries to read it you'll get a deadlock. I would suggest to use a critical section for synchronization.

Hope that helps,

Depends what you mean by up-to-date data.
If, for example, the common data includes a record structure, then when the single writer is filling in one record, a reader may be reading the record getting part of the new record and part of an old record. So, if the record being read should have some relational integrity, then a lock mechanism needs to be applied in order for the reader to obtain a snapshot of a valid record.

(There is also the question of whether you care whether multiple readers read the same data.)
Hi Zoppo,
In *nix without any locks, threads can read and write to shared area (perhaps with inconsistent results), but no deadlock occurs unless there are locks. Is this a special feature of WINAPI?
OWASP: Avoiding Hacker Tricks

Learn to build secure applications from the mindset of the hacker and avoid being exploited.

Hm - I'm not sure if this is WINAPI specific - I always thought this is a general problem (, but might be in *NIX there are thread-implementation which can avoid this problem ...
I was thinking that in general (*nix or other OS), that in absence of locks, then two threads or processes could read and write to the same byte or word and there cannot be deadlock (some wait states likely if the same address is accessed by both reader and writer concurrently). I did a search for "dead" in the link, but did not find it.

Only caveat to what I was saying is that if the read/write is to memory/mapped I/O, then it is possible that the HW could get into a state that could hose up the threads; but I didn't think that was the case here, since the OP would have mentioned memory mapped shared area (I would think).

The link is a good one to show when locks are needed.

For example, suppose the writer was writing an 16-byte crypto key. With no locks, a reader could start reading the key and get part of one key, and part of the previous key (or some unitialized garbage data).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
parabellumAuthor Commented:
Currently i have no locks in neither writer thread nor reader threads.

Let's say while a reader thread is reading a variable(say, a structrure) , the writer thread is changing it.

It does not matter if the value i get is old or meaningless just a piece of bytes in the memeory.
But does this cause a crash ? Because my application is currently crashing i am not sure about the reason  
Doesn't the reader need a snapshot of the structure, rather than just reading bytes in the structure. I don't see how writing and reading the same memory location concurrently (with wait states as mentioned earlier) can cause a crash in ordinary applications (i.e., not HW related applications). But it is easy to imagine applications where inconsistent data within a structure can cause inconsistent behavior and crashes. For example, if there is a length variable that is inconsistent with the object's true length (due to not getting a snapshot of the structure), then you could get a segment fault.

What kind of crash are you getting?

You can show the structure and that may give us clues. I'll be leaving soon; so Zoppo and others can continue this.

Are you able to use the debugger to help determine the cause of the crash?
No. You don't need to worry anything about the reader thread.
parabellumAuthor Commented:

Sorry for the late response. I am still not  100% sure about the subject but i will add multiple locks and see if the app still crashes.

Thank you all.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Editors IDEs

From novice to tech pro — start learning today.