104 of 105 people found the following review helpful
J. S. Hardman
- Published on Amazon.com
There are many views of how best to implement multi-threading and with multi-core processors now common the topic is becoming ever more relevant. Of course the best implementation method really depends on what you are trying to do. Are you implementing something that waits for a price update message from a derivatives exchange, parses the message, updates cached data, writes a log and forwards the message on to an algorithmic trading engine? If so, you'll probably be attracted to techniques different from someone calculating risk, bond prices etc. There is no one technique that suits every job.
Anyone working with multi-threading (and parallelism in general) keeps an eye on what techniques other people are using to see whether they may be useful. That's why I bought this book (Intel Threading Building Blocks) and TBB certainly looks like it will be of use for some multi-threaded applications that I develop, although not for all.
Starting with the most important question - have I learnt anything from reading this book. Yes, and I've learnt a couple of bits from reading the TBB source code too (downloadable from the web). Now for the detail...
Having read the book, am I now about to start using the Intel Threading Building Blocks library (downloadable from Intel)? The answer is yes, for some applications on some hardware architectures, but not for all of my multi-threaded applications. Importantly in terms of this book though, the first reason I looked at the TBB source code was to answer questions raised when reading the book, and that is my main issue with this book. For a developer who already has extensive multi-threading experience, this book raises quite a few questions that it doesn't answer.
Even some of the things that this book does answer are tucked away in the text a long way into the book. Here are three examples:
(1) The book tells you to create tasks, not explicitly work with threads. Where is the best description of a task? Page 267. It's not even in a glossary, but tucked away in the examples chapter. Somewhere in the first chapter would have been more useful.
(2) Personally, if I am told within the first few pages that TBB is based on the idea of developers implementing their systems as small tasks that are scheduled by the TBB scheduler I am immediately going to ask how that task is handled at a technical level. Ok, we're told quickly that it's written as a functor, and that functors may be executed on different cores, but does that mean that a thread is chosen from a thread pool to execute each functor, that (on Windows) fibers are used, that there is one manager thread running per core (with processor affinity set?) with each manager pulling tasks from its own queue, what are the performance implications of context switching and locking, etc? The author may think that the reader doesn't need this level of detail, but if somebody is going to the trouble of writing multithreaded code to improve performance I would think it very likely that they will want to know what is happening beneath the surface to ensure that they are using the best techniques. Some details of the scheduler are provided much further into the book (for instance we discover that last-in, first-out deques are used), but not enough and far too late.
(3) On page 133 there are two paragraphs discussing when task-based programming is inappropriate, a bit late in my opinion for those people for whom it does turn out to be inappropriate.
I also have issues with some of the things presented as absolute fact in the book. For example "Race conditions are less catastrophic than deadlocks". I disagree. With a deadlock your program stops, you know about it very quickly, you investigate and you sort it out. If it happens, it'll probably only happen once. With a race condition you may not even realise it exists, the application produces subtly incorrect results and hence your functionality goes awry. If that means your algorithmic trading engine decides to buy a million shares instead of doing nothing (or selling) then you are going to lose a lot of money very quickly. Possibly not just once, but day after day until you realise the race condition is there.
Then there are the bits that are just plain confusing. Here are two examples:
(a) We are told on page 271 that Task stealing is "Terrible" and "will disrupt cached data", but are told on page 283 that TBB is "unique because it rests on a few key decisions" including "Use task stealing". Hmmm...
(b) The code comment on page 231, "2 = 1 for SideShow and C". I know what it means, but adding a verb phrase would prevent the moment when the reader wonders just which proof is about to be presented that "2 = 1".
On the plus side, the book does discuss the split/join pattern, pipelines, atomic operations, benefits of working in user space, issues with the standard new operator (and hence libraries that make use of it), caching issues etc. There is also a chapter on general "Keys to Success" which is useful. There are also some reasonable examples towards the end of the book (although some half way through would be better replaced - demonstrating a point is one thing, but demonstrating it with realistic code is better).
Possibly outside the intended scope of the book, it might have been useful to briefly describe grid computing and whether Intel have plans to add a layer above TBB for use across grids instead of just on one machine, or whether Intel's plans for grid computing simply rely on a completely different model.
So to summarise, the TBB library from Intel looks like it could be very useful, this book will certainly get you started using it, but have no doubt that this book could have been better. Buy it if you will be using TBB, but until somebody writes a better book be prepared to read the TBB source code to find the answers to your deeper questions, or simply ask questions on Intel's web-site.