Experimental Physics and Industrial Control System
|
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
<2007>
2008
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
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|