1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
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 <gronager@ceptacle.com>) 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?= <gronager@ceptacle.com>
In-Reply-To: <CAPg+sBg16OPdyi3MQ+sfBR+z_ArP6c8KpU36pDA0MEdXpk9fxQ@mail.gmail.com>
Date: Fri, 3 Feb 2012 10:52:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CC24D9C-4207-4493-8C95-C5738B65C8B6@ceptacle.com>
References: <D55C3D18-8286-44E9-B877-6FCE7C05E980@ceptacle.com>
<CAJna-HiS34V5rNrRfFOMRJ6JhRmS1aeEE3oA=o07Hgf4S6qNfw@mail.gmail.com>
<54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com>
<CAD2Ti29cto8wS1jO5yOkORbE48c+t6Of2vysXcA0xM9LKCOCgg@mail.gmail.com>
<4CE9708D-0627-480C-B928-3F812544CD90@ceptacle.com>
<CAPg+sBg16OPdyi3MQ+sfBR+z_ArP6c8KpU36pDA0MEdXpk9fxQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Announcement: libcoin
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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/
|
