<blockquote>
  <p>Otherwise, it is advised to use the REST HTTP API with parallel queries, am I right?</p>
</blockquote>

<p>No. That would just add an extra layer of complexity and delay. Either the net result would be that some piece of code winds up trying to do more than one read at a time or it doesn't.</p>

<p>If it does result in some piece of code trying to do more than one read at a time, you're right back where you started. Does that code use a mutex or can it parallelize reads?</p>

<p>If it doesn't result in some piece of code trying to do more than one read at a time, you've just made things worse. You've added so much delay that the code can't even get around to starting one read until the previous one is finished.</p>

<p>So that would just push the problem around, not solve it.</p>

<blockquote>
  <p>If multiple reads from different threads is possible and there's no single mutex, it is advised to use the REST HTTP API with parallel queries, am I right?</p>
</blockquote>

<p>Why? To force the queries to be serial? That's what the mutex does without all the extra overhead of serializing requests and replies. To allow the queries to be done in parallel? If you could do the queries in parallel, you would just do them in parallel without the need for the extra overhead of this API.</p>

<p>What do you think the API does that makes things any better? There still either has to be code that can do the queries in parallel or the queries have to be serialized, you've just moved the problem to the other side of an API with huge, needless overhead.</p>

CC BY-SA 4.0
2020-04-21T17:53:33.363Z
I've clarified "otherwise".
MCCCS
CC BY-SA 4.0
2020-04-21T18:38:00.923Z
The answer is still "no" for the same reason. Either it leaves the queries in parallel (in which case, it has added an extra layer and not solved any problem) or it serializes them (in which case, it's so expensive that it's worse than a mutex).
David Schwartz
CC BY-SA 4.0
2020-04-21T17:49:05.773Z
2020-04-21T18:40:25.090Z
2020-04-21T18:40:25.090Z
David Schwartz
<p>Does Core have a mutex allowing one read at a time from the blockchain, or can reads be parallelized? If multiple reads from different threads is possible and there's no single mutex, it is advised to use the REST HTTP API with parallel queries, am I right?</p>

CC BY-SA 4.0
2020-04-20T14:54:12.047Z
I'm interested to this question, What does it mean `can reads be parallelized` from blockchain?
vincenzopalazzo
CC BY-SA 4.0
2020-04-20T15:35:15.363Z
Block database can be accessed at the same time from different threads of Core.
MCCCS
CC BY-SA 4.0
2020-04-21T21:24:44.597Z
I don't know what information you need but if you want to create an application to analyze the bitcoin data, you can use a parser for the Blk file. A parser for the blk file should be parallelized.
vincenzopalazzo
<bitcoin-core><blockchain><database>
Are Core's blockchain reads parallelized?
MCCCS
# Are Core's blockchain reads parallelized?

(Asked by: username_0 on 2020-04-20)

Does Core have a mutex allowing one read at a time from the blockchain, or can reads be parallelized? If multiple reads from different threads is possible and there's no single mutex, it is advised to use the REST HTTP API with parallel queries, am I right?

**Tags:** bitcoin-core, blockchain, database

> **Comments:**
> **username_1**: I'm interested to this question, What does it mean `can reads be parallelized` from blockchain?  
> **username_0**: Block database can be accessed at the same time from different threads of Core.  
> **username_1**: I don't know what information you need but if you want to create an application to analyze the bitcoin data, you can use a parser for the Blk file. A parser for the blk file should be parallelized.  

---

## 1 answers

### Answer by username_2 on 2020-04-21. Score: 1 | Accepted answer

> Otherwise, it is advised to use the REST HTTP API with parallel queries, am I right?

No. That would just add an extra layer of complexity and delay. Either the net result would be that some piece of code winds up trying to do more than one read at a time or it doesn't.

If it does result in some piece of code trying to do more than one read at a time, you're right back where you started. Does that code use a mutex or can it parallelize reads?

If it doesn't result in some piece of code trying to do more than one read at a time, you've just made things worse. You've added so much delay that the code can't even get around to starting one read until the previous one is finished.

So that would just push the problem around, not solve it.

> If multiple reads from different threads is possible and there's no single mutex, it is advised to use the REST HTTP API with parallel queries, am I right?

Why? To force the queries to be serial? That's what the mutex does without all the extra overhead of serializing requests and replies. To allow the queries to be done in parallel? If you could do the queries in parallel, you would just do them in parallel without the need for the extra overhead of this API.

What do you think the API does that makes things any better? There still either has to be code that can do the queries in parallel or the queries have to be serialized, you've just moved the problem to the other side of an API with huge, needless overhead.

> **Comments:**
> **username_0**: I've clarified "otherwise".  
> **username_2**: The answer is still "no" for the same reason. Either it leaves the queries in parallel (in which case, it has added an extra layer and not solved any problem) or it serializes them (in which case, it's so expensive that it's worse than a mutex).  

---

