2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== 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 |
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