parabellum
asked on
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 ?
Thanks.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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?
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?
Hm - I'm not sure if this is WINAPI specific - I always thought this is a general problem (http://en.wikipedia.org/wiki/Readers-writers_problem), but might be in *NIX there are thread-implementation which can avoid this problem ...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Currently i have no locks in neither writer thread nor reader threads.
Well,
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
Well,
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?
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?
In case you haven't used the VS debugger, here are some articles to introduce you to them. Note that it is for beginners, and doesn't cover multi-threading. https://www.experts-exchange.com/Programming/Languages/CPP/A_2688-Microsoft-Visual-Studio-2008-Express-C-Quick-and-Dirty-Debugger-Tutorial.html https://www.experts-exchange.com/Programming/Languages/CPP/A_3530-Breakpoint-Tips-for-C-C-Visual-Studio-2008-Debugger-Part-2.html https://www.experts-exchange.com/Programming/Languages/CPP/A_3532-C-C-Debugger-Tips-for-Visual-Studio-2008-Express-Part-3.html
No. You don't need to worry anything about the reader thread.
ASKER
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.
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.)