Exclusive (write) access to a variable/data structure
-
@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
@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 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.
How much overhead does lockForRead() incur (in terms of CPU cycles)?
-
How much overhead does lockForRead() incur (in terms of CPU cycles)?
@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 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.
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
-
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
@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 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...
@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 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)
This class is not meant to be derived from... use it as shown in the documentation.
-
This class is not meant to be derived from... use it as shown in the documentation.
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
-
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
@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 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.
@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