C and C++

[Jorgen Grahn]

I an nor so sure I would call that an information "leak", in a language
without the ability to tell the compiler to automatically call an
objects destructor, I wouldn't call listing a requirement that the
object needs its "close" function called before the object goes away an
encapsulation "leakage", it is just part of the objects interface. It
does say that when designing said interface, the designer needs to think
if there is now, or in some point in the future a possible need for such
an routine, and if so provide it and "require" its call. If anything, it
is the objects that do NOT require a "close" call that have leaked
implementation details, as if the future that changes, you need to
review all usage of that class.

Yes, the automatic calling of the "close" function simplify a lot of
code, but some of the critics of C++ also point out that this
automatisity is also a big problem as it can hide significant amounts of
operations.

Which critics? You hear this a lot from C programmers who like to
believe they have total control over the generated machine code (and
that C++ wants to rob them of it), but here we're comparing C++ with
languages like Java and Python, not C.

/Jorgen

 

[Öö Tiib]

I have implemented a similar system in our (largish) C++ software,
working only in Debug or test mode (for performance reasons, but also
because there is a large chance it would detect false positives in the
field and we are not sure what to do with them).

OK. That was what I suspected. There will be lot of (likely false)
alarms initially. False alarms are silenced by adjusting mutex levels.
When someone maintains something then that may cause again alarms (mostly
false positives) again some work, etc. At end it will work brilliantly
however. Deadlock never happens, add as lot of threads, peripherals
and what you need.

Yes, there are lots of mutexes on the same level. Whenever the program
attempts to lock a mutex on a less or equal level, this is a potential
deadlock scenario which has to get fixed. Setting up such a system is a
lot of work and the yield is seems pretty low, about 90% of times when
the alert triggers, it appears this is a false positive (meaning the lock
levels were assigned incorrectly and need readjusting). Maybe next time
it would work better, with more experience.

Yes, it is worth trying I trust. Some clever pattern (how to set it all
up with less work) may enter the world in that process and turn the
multi-threading into simple and clear.

The drawback of this system is that this is a runtime system and can only
detect deadlock scenarios which are actually run through in tests. What I
imagined in my previous post was to achieve the same at the compile time.

That involves some magic algorithm of automatic discovering of the "levels"
of mutexes that feels to be missing at the moment.