Application Design, Multi/Many-Core and Other Basics

When I’m writing about concurrency I do not mean Multi/Many-Core per se. This is just about a clarification on some basics and premises. Concurrency starts with processors that support multithreading (in order to overcome idle-times). This means in hardware (and a little bit simplified), program counters and programmable register sets are added. By doing this, processors are able to run more than one instruction stream at a time. In order to exploit this behavior, the software must be coded accordingly. If this is done, the code is ready for multithreading and for Multi/Many-Core processors. I admit that this sounds toooooooo ez. Coded accordingly means either a design from the scratch or a redesign in order to support concurrency. A rework could lead to a decomposition into software threats (please use the appropriate framework to handle threats, locking, synchronization, etc) or into sub-programs. Of course and as already mentioned a couple of times, arithmetic (code) and cash usage should be reviewed and considered as well. If the system is reworked into sub-programs, today’s multitasking operating systems will take care of this. Each approach should be considered thoroughly pertaining to pro and cons. Multithreading and Concurrency (using Multi/Many Core) might come with a higher effort in testing and in hunting nasty bugs. But let’s get back to the beginning of this blog entry. Multi-Threading and Multi/Many-Core are not the same technologies and buzz-words but highly complementary.