+ 1

Multiple read one write

Hi Please refer code below: I hope It is proper read write lock meaning one exclusive write lock where as shared read locks. Let me know if it is not so in shared code. Query is related to implementation. What does this guarantee? Shared mutex or shared lock ? https://sololearn.com/compiler-playground/c8clbCkBaUxf/?ref=app

26th Dec 2024, 11:02 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
18 Answers
+ 2
When I tried your code on msvc 2022, I found out the behavior was undefined compared to when I tried it on clang15 and g++14. I figure it out experimentally
26th Dec 2024, 2:01 PM
Badgirl MIRI
Badgirl MIRI - avatar
+ 2
Bob_Li you might be right. You don't get to see the code that has error but I have many compilers..it only terminate abruptly on clang15. The others are giving wrong output [0, 1, 1] as Ketan Lalcheta was curious about
28th Dec 2024, 9:44 AM
Badgirl MIRI
Badgirl MIRI - avatar
+ 2
But you should get one single result like either 0 or 1 from his objective Unlike batches of output like 0, 1, 1 which is always predictable then
28th Dec 2024, 10:34 AM
Badgirl MIRI
Badgirl MIRI - avatar
+ 1
Your code incorrectly use shared_mutex which can lead to undefined and does not properly implement a read-lock because In the read() function, you're using lock_guard<shared_mutex> which only locks the shared_mutex and prevents other threads (readers or writers) from accessing the resource simultaneously, defeating the purpose of shared locks. I think you should use shared_lock for readers and unique_lock for writers
26th Dec 2024, 1:09 PM
Badgirl MIRI
Badgirl MIRI - avatar
+ 1
https://en.cppreference.com/w/cpp/thread/shared_mutex I think shared_mutex can be used in both read and write. lock guard is supposed to lock out other threads when writing. Ketan Lalcheta but maybe void write() { lock_guard<shared_mutex> lg(m); ++data1; } void read() { shared_lock<shared_mutex> lg(m); cout << data1 << endl;; } write is supposed to modify data1 and read is to display it. your code is doing the opposite.
27th Dec 2024, 8:24 AM
Bob_Li
Bob_Li - avatar
+ 1
It (updated code currently present) seems good to me. Writing is exclusive and hence it is used in write method. Shared is properly used in read functions
27th Dec 2024, 8:29 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
+ 1
Issue was there earlier and it was updated once Badgirl MIRI pointed it correctly. Now my concern is that earlier wrong code should not be a undefined behaviour
27th Dec 2024, 8:30 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
+ 1
Ketan Lalcheta by law, write() function must have an exclusive lock and because it wasn't there, multiple thread can increment data1 at the same time leading to what's called a data race. Regarding the undefined behavior, I got the same output on msvc 2022 but a segmentation fault on clang15
27th Dec 2024, 8:35 AM
Badgirl MIRI
Badgirl MIRI - avatar
+ 1
Ketan Lalcheta just wondering if you're having the same compilation problems as Badgirl MIRI ? It's working ok here... I can compile and run you code in my laptop
27th Dec 2024, 10:15 AM
Bob_Li
Bob_Li - avatar
+ 1
What does multiple read one write mean goofy english please
27th Dec 2024, 5:57 PM
Bob Balinski
+ 1
🤪🤪🤪🤪
27th Dec 2024, 5:57 PM
Bob Balinski
+ 1
Bob_Li I am not sure on different compilers. wondering why compiler have seg fault on this. but to be honest, I have not tested it on other compiler
27th Dec 2024, 9:19 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
+ 1
Badgirl MIRI maybe it's a compiler incompatibility problem? Compilers are not required to support all language features and how they 're implemented when compiled is different for each compiler. So yes, it's a valid code for one compiler but not for another.
28th Dec 2024, 7:04 AM
Bob_Li
Bob_Li - avatar
+ 1
Threads are inherently non-deterministic. If I ran the code repeatedly, the results are not guaranteed to be 0 1 1. Sometimes I get 0 0 0....
28th Dec 2024, 10:26 AM
Bob_Li
Bob_Li - avatar
0
Thanks for correcting. Updated code. Why it would be undefined behaviour with read operation having lock guard and write having shared lock? Isn't that lead to data race and two threads may corrupt the data while writing . So, data race is not a avoided but behaviour is not dead lock or undefined. Correct or am I missing something 🤔?
26th Dec 2024, 1:22 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
How you come to conclusion about undefined behaviour? Just curious to know
27th Dec 2024, 4:44 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
Ketan Lalcheta what compiler were you using? I tested it and it works on when compiled via cli with g++, cl(msvc) and clang++.
28th Dec 2024, 3:11 AM
Bob_Li
Bob_Li - avatar
0
I only tested on sololearn
28th Dec 2024, 6:10 AM
Ketan Lalcheta
Ketan Lalcheta - avatar