You are viewing a single comment's thread from:
RE: Part 1/3: Order Matching Engine Requirements
hmmmm, these things bother me.
This order matching engine will be strictly single-threaded and purposeful.
bitshares is not of such that you can use any single-threaded thinking or implementation. Yes, your implementation should probably run in a single thread, it just has to iterate over the order books. However, your implementation will run in several places at several times.
It is hoped that the input will be clean and optimized (which could be offloaded) to improve throughput.
You can never count on clean inputs.
Thus you will clean and optimize inputs before handing it to your process.
If you build two modules, someone later can come and place something in between... thus you can never count on clean inputs.
Note that the beginning of the post was "academic exercise". This article is a repost from my website, where I was just walking through the thought process of designing an order book. So please do not assume this is the thought process for future iterations of BitShares. It is more like a technical article from a BitShares developer.
As for the "clean and optimized", that is why I put the "offloaded" comment in there. Such steps could be outside the matching engine code (separation of duties).
In this article, I wanted to make sure to narrow my focus on the matching engine and measuring for performance. It is a brief view for outsiders into the thinking process and experimentation of 1 developer. I gave my permission to repost articles from my blog, not thinking this would be one chosen. I hope this clears up any confusion