[vlc-devel] [PATCH] Make mutexes mutable
rom at rom1v.com
Tue Jan 9 13:19:22 CET 2018
Le mardi 9 janvier 2018 à 13:53 +0200, Rémi Denis-Courmont a écrit :
> On mardi 9 janvier 2018 12:46:12 EET Romain Vimont wrote:
> > Le mardi 9 janvier 2018 à 13:41 +0200, Rémi Denis-Courmont a écrit :
> > > On lundi 8 janvier 2018 21:45:16 EET Romain Vimont wrote:
> > > > Mutexes must be locked and unlocked even in C++ const methods. To avoid
> > > > const casts, simply declare them mutable.
> > >
> > > If you need to lock, then your method is not const. Conversely, if the
> > > object is guaranteed to be identical before and after the method call,
> > > then the methiod does not need to lock any mutex.
> > >
> > > I don't agree with your line of reasoning, and it seems that the C, POSIX
> > > and C++ don't either - otherwise they'd have lock and unlock as immutable
> > > methods too.
> > <http://en.cppreference.com/w/cpp/language/cv>
> I fail to see the relevance.
> > > mutable - applies to non-static class members of non-reference
> > > non-const type and specifies that the member does not affect the
> > > externally visible state of the class (as often used for mutexes, memo
> > > caches, lazy evaluation, and access instrumentation).
> Yeah and that's exactly why you should put the const qualifier for methods
> that DO NOT NEED to acquire any lock of any kind.
In C++, methods writing only members "that do not affect the externally
visible state of the class" should also be const (mutex, cache, lazy
Typically, using lazy evaluation or cache is an implementation detail,
it should not change the interface (the method signature).
That's the very purpose of the "mutable" keyword (logical const).
Item 16 ("Make const member functions thread safe") of _Effective Modern
C++_ provides more details and examples.
More information about the vlc-devel