Exclusive (write) access to a variable/data structure

[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