lock ownership enforcement in OO design

["Jeff Hill" <johill@lanl.gov>]

All,

 

To enforce mutex lock ownership, and allow lock overhead consolidation in complex designs, currently many of my classes look like this.

 

class Fred {

public:

            Fred ( epicsMutex & mutex ) : _mutex ( mutex ) {}

            Void doIt ( epicsGuard < epicsMutex > & guard, … ) { guard.assertIdenticalMutex ( _mutex ); }

private:

            epicsMutex & _mutex;

};

 

I am considering this alternative.

 

class Fred {

public:

            Fred ( epicsMutex & mutex ) : _mutex ( mutex ) {}

            Void doIt ( … ) { _mutex.assertOwnership (); }

private:

            epicsMutex & _mutex;

};

 

Negatives: runtime instead of compile time detection

Positives: Interfaces are simpler to look at, and more efficient too (no passing of guard references)

Neutral: With both approaches its much more obvious (compared to no enforcement) that lock hierarchies are inverted when independently developed codes call callbacks against each other. We can also remove detection logic from optimized builds.

 

Andrew has also suggested macros that eliminate guard argument passing from optimized builds as a 3^rd alternative.

 

Wadayathink?

 

Jeff
______________________________________________________
Jeffrey O. Hill           Internet     johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107