Multiple read one write

Question

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

Answer 1

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

Answer 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

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

What does multiple read one write mean goofy
english please

Answer 11

🤪🤪🤪🤪

Answer 12

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

Answer 13

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.

Answer 14

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

Answer 15

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 🤔?

Answer 16

How you come to conclusion about undefined behaviour? Just curious to know

Answer 17

Ketan Lalcheta
what compiler were you using?
I tested it and it works on when compiled via cli with g++, cl(msvc) and clang++.

Answer 18

I only tested on sololearn