4 ms·

> imperative concurrent programming is all about globals: the "shared variables" that have to do with the concurrency of the program, violate scoping: necessari

> imperative concurrent programming is all about globals: the "shared variables" that have to do with the concurrency of the program, violate scoping: necessarily so, because to be shared, they have to be accessible from multiple scopes. I may be nitpicking here but "accessible from multiple scopes" is not the same as being "all about globals". Data can usually still be localized to the routines that use it without throwing it in the global scope. The inherent problem of two threads sharing data is also something that will _have to_ be dealt with on some layer of the implementation if you want the threads to communicate, regardless of programming paradigm. Some languages provide really nice abstractions to deal with this in ways that don't explicitly have the programmers invoke locks. Among imperative languages, Go provides a really useful and sensible such abstraction with channels. > In concurrent programming, you are opening the doors to this type of problem: and what is worse is that shared variable x can change at any time, not over some predictable action like calling a function. When you assign 42 to x, x could turn into 43 even before control passes out of the assignment statement and to the next statement. Still nitpicking, but you should separate the concerns of parallel programming that don't necessarily have anything to do with concurrent programming. Imperative concurrent programming can be implemented by having routines explicitly yield control to other routines (e.g. protothreads, greenlets), making the execution order entirely predictable.

kazinator 12y ago
Explicit yielding of control is not concurrent programming, almost by definition. The execution order is entirely predictable precisely because it is serialized by the yield calls. The software specifically relies on these cooperative threads not being concurrent, such as "if I don't call anything which can yield, then nothing changes in a surprising way". Also, because it is not concurrency, it won't run on multiple processors. (There can be a loose order in cooperative threading in not knowing which thread will be run next when yield is called. It's still not serialized.)
- boomlinde 12y ago
  Again, note the difference between parallel execution and concurrent execution. The software specifically relies on these cooperative threads not being parallel, which is not an inherent property of being concurrent, most certainly by definition. Reading the first part of the article is a good start on understanding the distinction. Maybe this sort of lack of a basic understanding of the concepts is why concurrent programming is hard.
  - kazinator 12y ago
    There is no substantial difference between "parallel" and "concurrent". Bot mean "running side by side" except that by "parallel processing" we usually exclude simulated concurrency. However, simulated concurrency requires asynchronous behavior: an external event, such as a timer interrupt, or the arrival of input, can come in at any time and change the control among the tasks (preemption). This looks a lot like true parallelism and must be programmed with the same care as real parallelism, which is why we dare call it concurrency. Tasking without preemption is not concurrency. The tasks know that they cannot be preempted and rely on that assumption for their correctness. This approach falls into the same domain as the use of coroutines, or dispatch queues of lexical closures, first class continuations, generators and such: none of which represent concurrency. I do not believe I require any correction in terminology or concepts; I've been programming for 33 years, and I'm the person who invented and first implemented glibc's PTHREAD_MUTEX_ADAPTIVE_NP mutex back in 2000.

kazinator 12y ago

Explicit yielding of control is not concurrent programming, almost by definition. The execution order is entirely predictable precisely because it is serialized by the yield calls. The software specifically relies on these cooperative threads not being concurrent, such as "if I don't call anything which can yield, then nothing changes in a surprising way". Also, because it is not concurrency, it won't run on multiple processors. (There can be a loose order in cooperative threading in not knowing which thread will be run next when yield is called. It's still not serialized.)

boomlinde 12y ago
Again, note the difference between parallel execution and concurrent execution. The software specifically relies on these cooperative threads not being parallel, which is not an inherent property of being concurrent, most certainly by definition. Reading the first part of the article is a good start on understanding the distinction. Maybe this sort of lack of a basic understanding of the concepts is why concurrent programming is hard.
- kazinator 12y ago
  There is no substantial difference between "parallel" and "concurrent". Bot mean "running side by side" except that by "parallel processing" we usually exclude simulated concurrency. However, simulated concurrency requires asynchronous behavior: an external event, such as a timer interrupt, or the arrival of input, can come in at any time and change the control among the tasks (preemption). This looks a lot like true parallelism and must be programmed with the same care as real parallelism, which is why we dare call it concurrency. Tasking without preemption is not concurrency. The tasks know that they cannot be preempted and rely on that assumption for their correctness. This approach falls into the same domain as the use of coroutines, or dispatch queues of lexical closures, first class continuations, generators and such: none of which represent concurrency. I do not believe I require any correction in terminology or concepts; I've been programming for 33 years, and I'm the person who invented and first implemented glibc's PTHREAD_MUTEX_ADAPTIVE_NP mutex back in 2000.