đź“… Original date posted:2012-02-03
đź“ť Original message:> Hello Michael,
>
> I'm impressed by your refactorings, and hope some of them can make it into the Satoshi codebase.
Thanks:)
> I am however not sure what you've said above is safe. In particular, how do you guarantee that no other thread modifies the blockchain structure while you are performing your query on it? Does the query code operate on a const copy of the structure, or is there guaranteed only one thread accessing it?
The BlockChain class encapsulates all access to the blockchain and only give you access to certain restricted queries on the chain. Actually that was the case already in the satoshi client, I have only tried to formalize and encapsulate these queries in the code instead of having all the code poking around directly in the database and the blockfile.
I should note that the database still keeps a mutex to protect reads from writes.
I agree that constness alone does not guarantee thread safety, it is one of the things to use to get there. Great care should be taken not to read a value that is being changed at the same time, at least if that will render the result unusable.
The list of allowed queries are the const public methods of BlockChain. Some examples :
1. bool isSpent(Coin coin) const;
2. int getNumSpent(uint256 hash) const ;
3. uint256 spentIn(Coin coin) const;
/// Check if the hash of a block belongs to a block in the main chain:
4. bool isInMainChain(const uint256 hash) const;
/// Get the best height
5. int getBestHeight() const { return _bestIndex->nHeight; }
Or e.g.:
6. void getBlock(const uint256 hash, Block& block) const;
1-3. can be used to check if a COutPoint (now Coin) has been spent etc... This will only generate sane results, even if the two threads are both active on the same data structures.
Same goes for 4. and 6. copies a block from the block file to the Block& provided so no issues here either.
I do, however, admit, that an extra review of all the public const methods would be wise, to ensure that I have not overlooked something. I'll open an issue on this and use a cold winter night on looking them over again.
Cheers,
Michael
>
> I've been thinking about moving to read-write locks that allow multiple threads reading the datastructure simultaneously, but removing the locking all together sounds wrong to me.
>
> --
> Pieter
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager at ceptacle.com
Web: http://www.ceptacle.com/
Michael Grønager [ARCHIVE] /
npub15f…xlq6h
2023-06-07 03:03:32
in reply to nevent1q…8egx
Author Public Key
npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hPublished at
2023-06-07 03:03:32Event JSON
{
"id": "ff398d497171170d2970490ce17f59478114e986b97303a85a45f9732eb9f43e",
"pubkey": "a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f",
"created_at": 1686107012,
"kind": 1,
"tags": [
[
"e",
"8c8f8e5ac71e66999253086c48157eaa0ddb50daf23c9cafc1b7979613f23b3c",
"",
"root"
],
[
"e",
"258ec6da71c5c98b7b0a2d3e41c6398722cf4f1c0d5d97cd604381d446e8ffa4",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "đź“… Original date posted:2012-02-03\nđź“ť Original message:\u003e Hello Michael,\n\u003e \n\u003e I'm impressed by your refactorings, and hope some of them can make it into the Satoshi codebase.\n\nThanks:)\n\n\u003e I am however not sure what you've said above is safe. In particular, how do you guarantee that no other thread modifies the blockchain structure while you are performing your query on it? Does the query code operate on a const copy of the structure, or is there guaranteed only one thread accessing it?\n\nThe BlockChain class encapsulates all access to the blockchain and only give you access to certain restricted queries on the chain. Actually that was the case already in the satoshi client, I have only tried to formalize and encapsulate these queries in the code instead of having all the code poking around directly in the database and the blockfile.\n\nI should note that the database still keeps a mutex to protect reads from writes.\n\nI agree that constness alone does not guarantee thread safety, it is one of the things to use to get there. Great care should be taken not to read a value that is being changed at the same time, at least if that will render the result unusable.\n\nThe list of allowed queries are the const public methods of BlockChain. Some examples :\n1. bool isSpent(Coin coin) const;\n2. int getNumSpent(uint256 hash) const ;\n3. uint256 spentIn(Coin coin) const;\n\n /// Check if the hash of a block belongs to a block in the main chain:\n4. bool isInMainChain(const uint256 hash) const;\n \n /// Get the best height\n5. int getBestHeight() const { return _bestIndex-\u003enHeight; }\n\nOr e.g.:\n6. void getBlock(const uint256 hash, Block\u0026 block) const;\n\n1-3. can be used to check if a COutPoint (now Coin) has been spent etc... This will only generate sane results, even if the two threads are both active on the same data structures.\nSame goes for 4. and 6. copies a block from the block file to the Block\u0026 provided so no issues here either. \n\nI do, however, admit, that an extra review of all the public const methods would be wise, to ensure that I have not overlooked something. I'll open an issue on this and use a cold winter night on looking them over again.\n\nCheers,\n\nMichael\n\n\n\u003e \n\u003e I've been thinking about moving to read-write locks that allow multiple threads reading the datastructure simultaneously, but removing the locking all together sounds wrong to me.\n\u003e \n\u003e -- \n\u003e Pieter\n\nMichael Gronager, PhD\nDirector, Ceptacle\nJens Juels Gade 33\n2100 Copenhagen E\nMobile: +45 31 45 14 01\nE-mail: gronager at ceptacle.com\nWeb: http://www.ceptacle.com/",
"sig": "3976bc8eb2060e2bb14ea4743d6bead46676640a40fa01993044188e2a077fed5c34dd5c94bb7f0628969c1f3071faebf78c885eb4c5c14456ed2f1ab4daab14"
}