Dash - Reinventing Cryptocurrency
Go to file
Wladimir J. van der Laan 0e8a4d54a4
Merge #21064: refactor: use std::shared_mutex & remove Boost Thread
060a2a64d40d75fecb60b7d2b9946a67e46aa6fc ci: remove boost thread installation (fanquake)
06e1d7d81d5a56d136c6fc88f09a2b0654a164f9 build: don't build or use Boost Thread (fanquake)
7097add83c8596f81be9edd66971ffd2486357eb refactor: replace Boost shared_mutex with std shared_mutex in sigcache (fanquake)
8e55981ef834490c438436719f95cbaf888c4914 refactor: replace Boost shared_mutex with std shared_mutex in cuckoocache tests (fanquake)

Pull request description:

  This replaces `boost::shared_mutex` and `boost::unique_lock` with [`std::shared_mutex`](https://en.cppreference.com/w/cpp/thread/shared_mutex) & [`std::unique_lock`](https://en.cppreference.com/w/cpp/thread/unique_lock).

  Even though [some concerns were raised](https://github.com/bitcoin/bitcoin/issues/16684#issuecomment-726214696) in #16684 with regard to `std::shared_mutex` being unsafe to use across some glibc versions, I still think this change is an improvement. As I mentioned in #21022, I also think trying to restrict standard library feature usage based on bugs in glibc is not only hard to do, but it's not currently clear exactly how we do that in practice (does it also extend to patching out use in our dependencies, should we be implementing more runtime checks for features we are using, when do we consider an affected glibc "old enough" not to worry about? etc). If you take a look through the [glibc bug tracker](https://sourceware.org/bugzilla/describecomponents.cgi?product=glibc) you'll no doubt find plenty of (active) bug reports for standard library code we already using. Obviously not to say we shouldn't try and avoid buggy code where possible.

  Two other points:

  [Cory mentioned in #21022](https://github.com/bitcoin/bitcoin/pull/21022#issuecomment-769274179):
  > It also seems reasonable to me to worry that boost hits the same underlying glibc bug, and we've just not happened to trigger the right conditions yet.

  Moving away from Boost to the standard library also removes the potential for differences related to Boosts configuration. Boost has multiple versions of `shared_mutex`, and what you end up using, and what it's backed by depends on:
  * The version of Boost.
  * The platform you're building for.
  * Which version of `BOOST_THREAD_VERSION` is defined: (2,3,4 or 5) default=2. (see [here](https://www.boost.org/doc/libs/1_70_0/doc/html/thread/build.html#thread.build.configuration) for some of the differences).
  * Is `BOOST_THREAD_V2_SHARED_MUTEX` defined? (not by default). If so, you might get the ["less performant, but more robust"](https://github.com/boostorg/thread/issues/230#issuecomment-475937761) version of `shared_mutex`.

  A lot of these factors are eliminated by our use of depends, but users will have varying configurations. It's also not inconceivable to think that a distro, or some package manager might start defining something like `BOOST_THREAD_VERSION=3`. Boost tried to change the default from 2 to 3 at one point.

  With this change, we no longer use Boost Thread, so this PR also removes it from depends, the build system, CI etc.

  Previous similar PRs were #19183 & #20922. The authors are included in the commits here.
  Also related to #21022 - pthread sanity checking.

ACKs for top commit:
  laanwj:
    Code review ACK 060a2a64d40d75fecb60b7d2b9946a67e46aa6fc
  vasild:
    ACK 060a2a64d40d75fecb60b7d2b9946a67e46aa6fc

Tree-SHA512: 572d14d8c9de20bc434511f20d3f431836393ff915b2fe9de5a47a02dca76805ad5c3fc4cceecb4cd43f3ba939a0508178c4e60e62abdbaaa6b3e8db20b75b03
2024-01-16 09:29:52 -06:00
.github feat: Set client version for non-release binaries and version in guix based on git tags (#5653) 2024-01-11 21:43:42 -06:00
.tx fix: follow-up #5393 - should be used [dash.dash_ents] (#5472) 2023-07-01 14:16:50 +03:00
build-aux/m4 Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 2024-01-16 09:29:52 -06:00
ci Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 2024-01-16 09:29:52 -06:00
contrib Merge #20884: script: Improve robustness of bitcoind.service on startup 2024-01-16 09:29:46 -06:00
depends Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 2024-01-16 09:29:52 -06:00
doc Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 2024-01-16 09:29:52 -06:00
share feat: Set client version for non-release binaries and version in guix based on git tags (#5653) 2024-01-11 21:43:42 -06:00
src Merge #20211: Use -Wswitch for TxoutType where possible 2024-01-16 09:29:50 -06:00
test Merge #21117: test: remove assert_blockchain_height 2024-01-16 09:29:49 -06:00
.cirrus.yml Merge #18929: ci: Pass down LD_LIBRARY_PATH and MAKEJOBS to fuzz test_runner 2024-01-06 19:30:14 -06:00
.dockerignore build: add dash minimal development environment container 2021-12-21 12:43:37 +05:30
.editorconfig Merge #21123: code style: Add EditorConfig file 2021-07-16 10:04:09 -05:00
.fuzzbuzz.yml Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 2024-01-16 09:29:52 -06:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore merge bitcoin#19916: allow user to specify DIR_FUZZ_SEED_CORPUS for cov_fuzz 2024-01-10 12:11:18 -06:00
.gitlab-ci.yml feat: cache downloaded releases 2023-09-19 08:54:12 -05:00
.python-version partial bitcoin#27483: Bump python minimum version to 3.8 2023-05-11 09:18:48 -05:00
.style.yapf Merge #15533: test: .style.yapf: Set column_limit=160 2021-07-10 12:10:51 -05:00
.travis.yml Merge #19008: ci: tsan on clang-9 2024-01-06 19:30:14 -06:00
autogen.sh Merge #17829: scripted-diff: Bump copyright of files changed in 2019 2023-12-06 11:40:14 -06:00
CMakeLists.txt chore: Added missing sources files in CMake (#5503) 2023-07-25 12:23:56 -05:00
configure.ac Merge #21064: refactor: use std::shared_mutex & remove Boost Thread 2024-01-16 09:29:52 -06:00
CONTRIBUTING.md Merge #19072: doc: Expand section on Getting Started 2023-12-06 11:40:14 -06:00
COPYING Bump copyright year to 2020 (#3290) 2020-01-17 15:42:55 +01:00
INSTALL.md Dashify INSTALL.md and build-unix.md 2018-01-12 16:12:54 +01:00
libdashconsensus.pc.in revert dash#1432: Rename consensus source library and API 2022-08-09 14:16:28 +05:30
Makefile.am merge bitcoin#19916: allow user to specify DIR_FUZZ_SEED_CORPUS for cov_fuzz 2024-01-10 12:11:18 -06:00
README.md chore: drop version from README.md which is not really useful (#5811) 2024-01-10 12:12:41 -06:00
SECURITY.md Merge bitcoin/bitcoin#23466: doc: Suggest keys.openpgp.org as keyserver in SECURITY.md 2022-04-03 18:46:47 -05:00

Dash Core staging tree

CI master develop
Gitlab Build Status Build Status

https://www.dash.org

For an immediately usable, binary version of the Dash Core software, see https://www.dash.org/downloads/.

Further information about Dash Core is available in the doc folder.

What is Dash?

Dash is an experimental digital currency that enables instant, private payments to anyone, anywhere in the world. Dash uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Dash Core is the name of the open source software which enables the use of this currency.

For more information read the original Dash whitepaper.

License

Dash Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is meant to be stable. Development is normally done in separate branches. Tags are created to indicate new official, stable release versions of Dash Core.

The develop branch is regularly built (see doc/build-*.md for instructions) and tested, but is not guaranteed to be completely stable.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The Travis CI system makes sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Dash Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.