Exclusive (write) access to a variable/data structure

deisik

@JonB said in Exclusive access to a variable/data structure:

If your stated goal is "Exclusive access to a variable/data structure", i.e. sharable, and across multiple threads, then what else do you have in mind? Might be different if you wanted to, e.g. send a copy via a signal, but you don't....

Basically, I need 2 things

No read operation can start until the write operation is over
No write operation can start until all reads are finished

Note that I don't need to synchronize read operations as such. Multiple concurrent reads are okay and must be allowed

I use a flag which (seemingly) enables 1. For 2, I thought about implementing a counter which gets incremented on a read operation. But then I realized that this counter itself can get corrupted on concurrent writes by data read operations

@J-Hilk said in Exclusive access to a variable/data structure:

prayer

I'm already past that point

Christian Ehrlicher

Take a look at QReadWriteLock

mpergand

@deisik
One alternative could be to use signals & slots,
when a change occurs, a signal is emitted to the connected receivers.
In queue mode the signal is emitted in the receiver thread (assuming the thread has an event loop).
see here :
https://stackoverflow.com/questions/15051553/qt-signals-queuedconnection-and-directconnection

deisik

@mpergand said in Exclusive (write) access to a variable/data structure:

@deisik
One alternative could be to use signals & slots,
when a change occurs, a signal is emitted to the connected receivers.
In queue mode the signal is emitted in the receiver thread (assuming the thread has an event loop).
see here :
https://stackoverflow.com/questions/15051553/qt-signals-queuedconnection-and-directconnection

It would require a two-way communication, so how do you imagine it?

deisik

@Christian-Ehrlicher said in Exclusive (write) access to a variable/data structure:

Take a look at QReadWriteLock

That seems to be the thing

tryLockForRead() and tryLockForWrite() are the functions that I need

JonB

@deisik
It's the same principle as with QMutexs, which also have the try...()-type methods.

https://doc.qt.io/qt-6/qreadwritelock.html#details

In many cases, QReadWriteLock is a direct competitor to QMutex. QReadWriteLock is a good choice if there are many concurrent reads and writing occurs infrequently.

And, yes, as you say, don't use your own flag as accessing that will be race condition :)

Christian Ehrlicher

@deisik said in Exclusive (write) access to a variable/data structure:

tryLockForRead() and tryLockForWrite() are the functions that I need

You really better should use QReadLocker and QWriteLocker for this task.

deisik

@Christian-Ehrlicher

How much overhead does lockForRead() incur (in terms of CPU cycles)?

Christian Ehrlicher

@deisik It depends on your cpu, compiler and optimization level. Why is this important? You need a locking mechanism so use one. If you have problems with the speed later on then do profiling.

deisik

@Christian-Ehrlicher

You see, I need this feature only in very specific cases, but the data structure for which I need it is used application-wide. So if I could just inherit from QReadWriteLock for this class and make calls to its internal data tree lock-aware, it would greatly simplify things

Christian Ehrlicher

@deisik said in Exclusive (write) access to a variable/data structure:

So if I could just inherit from QReadWriteLock f

Why inherit from this? There is no need for this...

deisik

@Christian-Ehrlicher said in Exclusive (write) access to a variable/data structure:

@deisik said in Exclusive (write) access to a variable/data structure:

So if I could just inherit from QReadWriteLock f

Why inherit from this? There is no need for this...

Why not if it doesn't incur significant overhead? It feels like a logical choice to me. You just lock/unlock a data object when you need without overthinking it (this is not to say you shouldn't think it over)

Christian Ehrlicher

This class is not meant to be derived from... use it as shown in the documentation.

deisik

@Christian-Ehrlicher

Okay, I implemented both approaches (by inheriting QReadWriteLock and by using a local QReadWriteLock object). I didn't notice any difference – both implementations are working just fine, and block access as designed

But personally, I'm going to stick with subclassing QReadWriteLock as it feels like a lot more authentic way of doing things in C++, and you don't need to bother about helper functions (you can lock the entire data object directly) while not having to handle a separate QReadWriteLock object within the class itself

SGaist

@deisik composition is a core part of C++ and is encouraged over inheritance. You usually inherit when you want to augment the base class with new capabilities. In your case, you are leaking implementation details by doing so. If you need to lock the access to the whole data structure, then maybe you were putting the original lock in the wrong place.

deisik

@SGaist said in Exclusive (write) access to a variable/data structure:

@deisik composition is a core part of C++ and is encouraged over inheritance

Then why care about C++ at all?

You usually inherit when you want to augment the base class with new capabilities. In your case, you are leaking implementation details by doing so

Leaking to whom or what, and why is it inherently a bad thing?

If you need to lock the access to the whole data structure, then maybe you were putting the original lock in the wrong place

Yes, when I need to dramatically change its contents. When I need to change/retrieve from another thread a single element in a list, I now use QReadWriteLock-enabled versions of regular getter/setter functions