GCD for parallelism (But Not That GCD) ... but maybe GDC?
Tracey and I end up giving talks on software development and engineering in all kinds of contexts in front of folks who are from all kinds of operating system communities. We do intentionally divide folks by operating system here because individuals and organizations tend to identify themselves that way. We often hear "I'm a Window's user", or "Our organization has standardized on Solaris", or "We only support MacOSX" and so forth.And it is true that in general the operating system is the ultimate layer of software that stands between you and what the computer is capable of doing. The operating system can provide a limited view of the hardware's capability to the user, or it could provide an unlimited view of the hardware's capability to the user. So I guess it may be somewhat fair for someone to announce their computer identity with being part of some operating system user's group.
The unfortunate thing is that each operating system tends to speak its own language. The operating system often offers proprietary sometimes version driven solutions to problems. This usually leads to each operating system introducing its own set of questions with operating system specific answers. For example, Mac OSX offers GCD (Grand Central Dispatch) as the answer to the question of how do developers deal with the new multicore hardware capabilities in the context of trying to provide the Apple experience. Of course Google's/ OHA's Android, IBM's Z/OS, or Sun's Solaris don't quite give the same answer. But in fairness depending on the OS, the question will be asked a little differently to usually a different user group. So Tracey and I survive by using the GCD for all systems. Not the aforementioned GCD but the GCD as in Greatest Common Divisor. We simply don't have the time or manpower to develop, maintain, or recommend proprietary software designs. We have to interact with far too many user groups for that. So we use languages, tools, paradigms that are available in main stream operating system environments. For us this has meant the adoption of the POSIX standards for Operating Systems and the ISO standard for computer languages. While neither set of standards are perfect, they have allowed us to not only survive the morass of competing operating systems and user groups but to be effective. These standards also allow us to focus on the problem and on producing lasting, robust solutions, instead of getting tricked or mired down into some OS-specific-Vendor-specific scheme. At the end of the day all of the talk about models of parallelism and multicore programming techniques have to be implemented so that they can be executed by the computer (or cloud if you prefer). We usually specify those implementations so that they are compliant with the POSIX standards for operating systems and are implemented in some ISO standard language(s).
So for those of you that have written to us and asked what tools we use and recommend, the official answer is we use the GCD (Not that GCD) for most main stream operating systems. The GCD tends to be made up POSIX compliant environments & tools and ISO compliant languages, although our use of Java is an exception to these to standards. The same is especially true for the majority of our parallel or multicore programming techniques. They will be expressed using POSIX compliant methods and ISO compliant languages (usually C++ and Prolog). These are our preferences because they have worked in more scenarios and environments and under the most outrageous conditions than we have time to list. We use a very small set of tools across all the platforms we develop for. But our other secret weapon for parallelism is GDC (Guarded Definite Clause - we'll leave that one for later).