Call sync.h primitives "locks" and "mutexes" instead of "blocks" and "waitable
critical sections" to match current coding conventions and c++11 standard
names.
This PR does not rename the "CCriticalSection" class (though this could be done
as a followup) because it is used everywhere and would swamp the other changes
in this PR. Plain mutexes should mostly be preferred instead of recursive
mutexes in new code anyway.
-BEGIN VERIFY SCRIPT-
set -x
set -e
ren() { git grep -l $1 | xargs sed -i s/$1/$2/; }
ren CCriticalBlock UniqueLock
ren CWaitableCriticalSection Mutex
ren CConditionVariable std::condition_variable
ren cs_GenesisWait g_genesis_wait_mutex
ren condvar_GenesisWait g_genesis_wait_cv
perl -0777 -pi -e 's/.*typedef.*condition_variable.*\n\n?//g' src/sync.h
-END VERIFY SCRIPT-
(cherry picked from commit bitcoin/bitcoin@190bf62be1)
They should also work with any other mutex type which std::unique_lock
supports.
There is no change in behavior for current code that calls these macros with
CCriticalSection mutexes.
(cherry picked from commit bitcoin/bitcoin@1382913e61)
Move AnnotatedMixin closer to where it's used, and after the DEBUG_LOCKORDER
function declarations so it can call them.
(cherry picked from commit bitcoin/bitcoin@ba1f095aad)
Commit 1.
This code was written by @TheBlueMatt in the following branch:
* https://github.com/TheBlueMatt/bitcoin/commits/2017-08-test-10923
This commit message was written by me (@practicalswift) who also squashed
@TheBlueMatt's commits into one and tried to summarize the changes made.
Commit 2.
Remove boost include. Remove boost mentions in comments.
(cherry picked from commit bitcoin/bitcoin@7e319d6393)
The lockorder potential deadlock detection works by remembering for each
lock A that is acquired while holding another B the pair (A,B), and
triggering a warning when (B,A) already exists in the table.
A and B in the above text are represented by pointers to the CCriticalSection
object that is acquired. This does mean however that we need to clean up the
table entries that refer to any critical section which is destroyed, as it
memory address can potentially be used for another unrelated lock in the future.
Implement this clean up by remembering not only the pairs in forward direction,
but also backward direction. This allows for fast iteration over all pairs that
use a deleted CCriticalSection in either the first or the second position.
zcash: cherry picked from commit 5eeb913d6cff9cfe9a6769d7efe4a7b9f23de0f4
zcash: https://github.com/bitcoin/bitcoin/pull/7846
This allows us to use function/variable/class attributes to specify locking
requisites, allowing problems to be detected during static analysis.
This works perfectly with newer Clang versions (tested with 3.3-3.7). For older
versions (tested 3.2), it compiles fine but spews lots of false-positives.
Rebased by @laanwj:
- update for RPC methods added since 84d13ee: setmocktime,
invalidateblock, reconsiderblock. Only the first, setmocktime, required a change,
the other two are thread safe.
- ensures a consistent usage in header files
- also add a blank line after the copyright header where missing
- also remove orphan new-lines at the end of some files
Use misc methods of avoiding unnecesary header includes.
Replace int typedefs with int##_t from stdint.h.
Replace PRI64[xdu] with PRI[xdu]64 from inttypes.h.
Normalize QT_VERSION ifs where possible.
Resolve some indirect dependencies as direct ones.
Remove extern declarations from .cpp files.
o Remove unused Leave and GetLock functions
o Make Enter and TryEnter private.
o Simplify Enter and TryEnter.
boost::unique_lock doesn't really know whether the
mutex it wraps is locked or not when the defer_lock
option is used.
The boost::recursive_mutex does not expose this
information, so unique_lock only infers this
knowledge. When taking the lock is defered, it
(randomly) assumes that the lock is not taken.
boost::unique_lock has the following definition:
unique_lock(Mutex& m_,defer_lock_t):
m(&m_),is_locked(false)
{}
bool owns_lock() const
{
return is_locked;
}
Thus it is a mistake to check owns_lock() in Enter
and TryEnter - they will always return false.