From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RtFop-0005Fv-LX for bitcoin-development@lists.sourceforge.net; Fri, 03 Feb 2012 09:52:35 +0000 X-ACL-Warn: Received: from 2508ds5-oebr.0.fullrate.dk ([95.166.54.49] helo=mail.ceptacle.com) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RtFok-0002lO-AR for bitcoin-development@lists.sourceforge.net; Fri, 03 Feb 2012 09:52:35 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ceptacle.com (Postfix) with ESMTP id 7659016A0D8C; Fri, 3 Feb 2012 10:52:24 +0100 (CET) X-Virus-Scanned: amavisd-new at ceptacle.com Received: from mail.ceptacle.com ([127.0.0.1]) by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKqGxzef+voY; Fri, 3 Feb 2012 10:52:23 +0100 (CET) Received: from [109.105.106.198] (unknown [109.105.106.198]) by mail.ceptacle.com (Postfix) with ESMTPSA id A7DA416A0D76; Fri, 3 Feb 2012 10:52:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_Gr=F8nager?= In-Reply-To: Date: Fri, 3 Feb 2012 10:52:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8CC24D9C-4207-4493-8C95-C5738B65C8B6@ceptacle.com> References: <54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com> <4CE9708D-0627-480C-B928-3F812544CD90@ceptacle.com> To: Pieter Wuille X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1RtFok-0002lO-AR Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Announcement: libcoin X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 09:52:35 -0000 > Hello Michael, >=20 > 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; =20 /// 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.=20 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 >=20 > 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. >=20 > --=20 > Pieter Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: gronager@ceptacle.com Web: http://www.ceptacle.com/