EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: lock ownership enforcement in OO design
From: Eric Norum <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'EPICS core-talk'" <[email protected]>
Date: Fri, 1 Jun 2007 15:46:52 -0500
On Jun 1, 2007, at 3:41 PM, Jeff Hill wrote:

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 3rd alternative.



Wadayathink?



Andrew and I discussed some of the technical issues.
I see no showstoppers, even on multi-CPU, multi-cache, machines -- thought I don't think that my crushing logic has completely convinced Andrew yet.....

Another benefit would be that it would be useful to have the task id of a mutex holder exposed as a API-accessible value when trying to diagnose deadlocks.
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793




Replies:
Re: lock ownership enforcement in OO design Andrew Johnson
References:
lock ownership enforcement in OO design Jeff Hill

Navigate by Date:
Prev: lock ownership enforcement in OO design Jeff Hill
Next: Re: lock ownership enforcement in OO design Kay-Uwe Kasemir
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: lock ownership enforcement in OO design Jeff Hill
Next: Re: lock ownership enforcement in OO design Andrew Johnson
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·