← Back to context

Comment by titzer

3 years ago

Parallelism and concurrency are different models. It is not a needless distinction.

With just concurrency, you can have a system, e.g. an event processing system, where each event happens, is processed to completion, and then the next event is processed. Events can be of different types and can have different handlers. Events can be arrive (or be delivered) in different orders. The context-switching points are known (in this case, the beginning and end of event processing). As such, any computation between context switching points appears to happen atomically (i.e. no partial update, no internal reordering).

Parallelism is a different model.

There are no well-defined, limited set of interaction points between computations. A computation could literally be interrupted at any machine-level instruction and another computation start running. Suddenly, the number of possible interactions is huge--almost beyond comprehension. Locks, transactions, or other synchronization mechanisms are necessary in order to create larger atomic regions (and defend against race conditions). Worse, with weak memory models, which most modern multi-core hardware have, means that interleaving alone is not enough to explain the possible interactions between threads. It's possible with weak memory models that writes from another computation appear in different orders to different threads. Weak memory models make avoiding race conditions absolutely paramount.

This is word salad. Sorry.

What are you modeling?

The way you use "concurrency" it's indistinguishable from code without any signs of parallelism. From your "definition", concurrency is just any code. Such definitions are called "trivial" if you don't want to offend the author, and "worthless" if you are honest.

Your attempt at defining "parallelism" is even worse... You start by calling it undefined, and then proceed throwing poorly connected verbs and nouns...

Let me make it simple:

Parallel or concurrent code is code that doesn't require time interval between instructions (this is in contrast to Von Neumann model, where it's necessary to have a non-zero time span between instructions).

Here. That's it. No "but hardware", no "there are no well-defined" etc.

  • Your comment is subtractive from the discussion and its tone and attitude is not OK. If you came here to make no attempt to understand what people have written, even when they are explaining words, defining terms, and instead attack them and shout past them, we're better off if you didn't.

    I wouldn't normally put such a fine point on it, but in this thread you've managed to make a lot of noise and calls lots of things "nonsense". If you're after emotional responses and heated discussion, that's tantamount to trolling, and you should stop.

  • a program which is concurrent expresses logically independent paths of execution, which can be executed one after the other, or at the same time, or any mix thereof -- it is a logical property of the program as expressed, and not necessarily exploited, or observable, when the program is run

    a program which is parallel actively demonstrates multiple paths of execution during runtime -- it is a physical property of the program as executed

    tl;dr: every parallel program is concurrent, not every concurrent program is parallel