> Well, very few people like these words, to be honest, and parallelism and > concurrency are pretty much used interchangeably these days. Going against > this is a bit like trying to convince the world that "hacking" doesn't mean > "illegally breaking into".
Isn't it just a matter of which abstraction level you are looking at it from? Concurrency is a property of the program, parallelization is a property of the execution machinery. For (parts of) a program to be executed in parallel, it follows that it must be designed for concurrency. > I'm curious, though: if parallelization is one type of concurrency, what are > the other types? Asynchronously? An asyncronous program may not execute anything in parallel, but its state-space is defined as non-syncronous. When I write GWT applications, I must specifically write asyncronous callbacks because I can not block until the call completes. In general, and in the context of Java, I think this debate lacks a separation of asynchronously (logical vs. physical flow of control, often side-effect bound like doing I/O) vs. computational parallelization (divide-and-conquer, side-effect unbound). The 80/20 rules seems to apply in that the majority of developers really needs only concern themselves with asynchronously and "submitting work", while a minority actually needs to specifically think about doing fine-grained stuff in parallel - it's almost a new go-round of "The simplest possible solution is usually the best". In practice, the balance between hot code and Amdahl's law may simply not be worth it below a certain threshold. I mean, the remaining cores will service other threads or simply go to sleep at no cost to performance/wattage. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
