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: Andrew Johnson <[email protected]>
To: Eric Norum <[email protected]>
Cc: "'EPICS core-talk'" <[email protected]>
Date: Fri, 01 Jun 2007 18:15:07 -0500
In general I agree with Kay; you have a working design, and any change now would require spending time deleting all the guard parameters and changing the tests. I'm not that keen on the idea of using macros to remove the guards either -- nobody actually builds EPICS with NDEBUG defined that I know of, and I wouldn't be to surprised if some things actually stop working when built like that - I've fixed more than one routine in the last few years that was doing processing inside an assert() statement.

Eric Norum wrote:

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.....

I have don't like going beyond what is strictly guaranteed by the threading primitive libraries that we're using in portable code, and I think it's fair to say that we'd be outside what Posix promises.

pthread_mutex_lock() provides a read barrier (think cache-invalidate); pthread_mutex_unlock() provides a write barrier (cache-flush). The guaranteed synchronization requirements are that a write barrier must follow the last write to the protected data, and a read barrier precede the first read. Attempting to read before the read barrier could give you anything, and that's what we'd be doing by comparing the mutex.threadId with ours without.

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.

Careful, that task id might not be visible from threads across a CPU boundary; if we offer the thread ID as a mutex method we'd risk this not working in some circumstances (or we'd have to have a mutex to protect the mutex...). Just because you only intend that API for debugging doesn't mean that it won't get used in regular code...

- Andrew
--
The right to be heard does not automatically include
the right to be taken seriously. -- Hubert H. Humphrey

References:
lock ownership enforcement in OO design Jeff Hill
Re: lock ownership enforcement in OO design Eric Norum

Navigate by Date:
Prev: Re: lock ownership enforcement in OO design Kay-Uwe Kasemir
Next: SoftIocMain.cpp Ralph Lange
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: Re: lock ownership enforcement in OO design Eric Norum
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 
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 ·