3 ms·

Consider a language runtime for which every thread takes the same global lock on the interpreter, and therefore prevents two threads running 'simultaneously'. Y

by javert 16y ago

Consider a language runtime for which every thread takes the same global lock on the interpreter, and therefore prevents two threads running 'simultaneously'. You have concurrency but no parallelism. Well, I disagree that "concurrency" should be defined as "having multiple threads," but if that's how we want to define it... then I think you conflated the definitions half way through. Your final example, you state, has neither concurrency nor parallelism. Actually, by your definition of concurrency, it could be concurrent (put each statement in a separate thread and use locks), though I agree that it can't be parallel; it's inherently sequential.

ww520 16y ago
What are your definition of concurrency and parallelism?
- javert 16y ago
  At first I didn't have any, but now I've come up with the following: Concurrency occurs when program semantics allow two threads of execution to be executed in a simultaneous or interleaved manner. Parallelism occurs when two program threads actually execute simultaneously.
HenryR 16y ago
These are tricky waters, but here's what I see as the difference: Two separate threads that can run completely independently without any synchronisation are concurrent because it doesn't matter what order you run them in. Therefore there are many, many 'sequentially equivalent' computations that are correct per the language semantics. From the perspective of the user it can seem like you ran Thread A to completion followed by Thread B, or Thread B then Thread A, or any interleaving of the two. Threads are one way of expressing concurrency. Actors, to pick at random, are another. So I don't believe that threads <=> concurrency, but that threads usually express concurrency unless they have pathological synchronisation behaviour. Which they would have, in your final example - there is no concurrency because there's only a single ordering of events that is correct.
- javert 16y ago
  I just realized you and I have multiple "threads of conversation" going on at once. (which is OK.) I like your Actors example. Yeah, concurrency can't be defined in terms of "threads" in a specific implementation sense, but only in a more generic sense of "threds of execution," as in "execution contexts".

by javert 16y ago

ww520 16y ago

What are your definition of concurrency and parallelism?

javert 16y ago
At first I didn't have any, but now I've come up with the following: Concurrency occurs when program semantics allow two threads of execution to be executed in a simultaneous or interleaved manner. Parallelism occurs when two program threads actually execute simultaneously.

HenryR 16y ago

These are tricky waters, but here's what I see as the difference: Two separate threads that can run completely independently without any synchronisation are concurrent because it doesn't matter what order you run them in. Therefore there are many, many 'sequentially equivalent' computations that are correct per the language semantics. From the perspective of the user it can seem like you ran Thread A to completion followed by Thread B, or Thread B then Thread A, or any interleaving of the two. Threads are one way of expressing concurrency. Actors, to pick at random, are another. So I don't believe that threads <=> concurrency, but that threads usually express concurrency unless they have pathological synchronisation behaviour. Which they would have, in your final example - there is no concurrency because there's only a single ordering of events that is correct.

javert 16y ago
I just realized you and I have multiple "threads of conversation" going on at once. (which is OK.) I like your Actors example. Yeah, concurrency can't be defined in terms of "threads" in a specific implementation sense, but only in a more generic sense of "threds of execution," as in "execution contexts".