|WikiProject Computing||(Rated Start-class)|
|WikiProject Computer science||(Rated Start-class, Mid-importance)|
Merged content from Concurrent programming language
See Talk:Concurrent programming language for earlier discussions on concurrent programming languages, as well as dicussion on the merge into Concurrent computing. --Allan McInnes 07:03, 27 January 2006 (UTC)
what is concurrency control
The concurrent computing article currently claims
- "However, since both processes perform their withdrawals, the total amount withdrawn will end up being more than the original balance. These sorts of problems with shared resources require the use of concurrency control, or non-blocking algorithms."
Currently, the concurrency control article seems to be talking *only* about databases.
What about all the algorithms listed in Category:Concurrency control that involve blocking, but do not involve databases? Algorithms such as serializing tokens and mutual exclusion and monitor (synchronization)? Aren't they also perfectly valid ways of dealing with this sort of problem?
We need to either
- Change this "concurrent computing" article to add another category of solutions, "These sorts of problems with shared resources require the use of concurrency control, ((new category here that includes monitors, etc.)), or non-blocking algorithms.". Or
- Change the concurrency control article to discuss all blocking algorithms (whether or not they require a database).
- change this "concurrent computing" article to *remove* a category of solutions, "These sorts of problems with shared resources require the use of concurrency control". And change the "concurrency control" article to discuss all the algorithms in Category:Concurrency control, blocking and non-blocking.
What is a good name for this "new category" (things like monitors, mutexes, serializing tokens, etc)?
Or is there a better 4th option?
--220.127.116.11 15:08, 23 September 2006 (UTC)
Types of concurrency
Atleast accordigng to CTM Book the three variants are
- Shared memory concurrency
- Message Passing concurrency
- Dataflow concurrency
- Dataflow variables are a kind of future. The listing of shared memory and message-passing in the article is referring to forms of explicit communication between threads (as opposed to the presumably "implicit" communication inherent in a future). The implied dichotomy between futures and other methods of communication is perhaps not correct, and it's certainly not well explained in the article. If you'd like to take a stab at rewriting it, I'd be interested to see what you come up with. --Allan McInnes (talk) 23:24, 1 October 2008 (UTC)
Can someone clean up the definition so someone can actually understand the difference between parallel and concurrent computing?
Parallel computing is the execution of the exact same algorithm at the same time. Concurrent computing is the excetuion of multiple, but not necessarilly the same, software at the same time.
That's the only difference. Parallel computing IS concurrent computing. But concurrent computing is not always parallel computing. Although unlikely, they don't need to interact either.—The preceding unsigned comment was added by 18.104.22.168 (talk) 07:42, 16 February 2007 (UTC).
That's wrong. Parallelism is a property of computers, meaning that the control flow executes on multiple pathways in parallel. Concurrency, on the other hand, is a property of programs and programming languages, meaning they have constructs designed to exploit parallelism. Note that concurrent programs can run on ordinary, sequential computers as well -- simply by `simulating' parallelism, for example with multithreading --, and that ordinary sequential programs can exploit parallelism if the compiler performs appropriate transformations/optimizations. So parallelism and concurrency are closely related, but both express a different view of what one might call the same underlying idea. The article currently blurs the distinction between parallelism and concurrency, which is very unfortunate as the distinction is widely agreed upon in computer science and very useful from an educational and engineering point of view. Without this distinction, it becomes very difficult to concisely and precisely talk about things like realizing concurrency in the presence or absence of different forms of parallelism. I would be glad if the article could be modified to take this into account; however, I would leave this change to someone who is more familiar with the article. To reinforce my point, consider the following: The term `hardware parallelism' does not exist in the form of `hardware concurrency', while things like the pi-calculus are consistently referred to as designed for `concurrent' systems (the Wikipedia article itself follows this notion).
Merge with Concurrency (computer science)?
- No, I don't think so. The Concurrency (computer science) article deals (or should deal) with defining the term "concurrency" as it's used in computer science, and discussing both its theoretical (some of which have little to do with concurrent computing) and practical aspects (in overview). The concurrent computing article should cover the practical aspects and applications of concurrency in programs. --Allan McInnes (talk) 01:43, 13 May 2009 (UTC)
- No. They are different areas and involve different concerns. Concurrent computing involves writing programs that contain independent parts that may (but don't have to be) executed in parallel. For example, sometimes programs are made concurrent just to make them appear more responsive by running time-consuming but non-time-critical tasks "in the background", with no intention of running them on parallel processors. Parallel computing deals with the specific problems of writing programs intended to be run on multiple processors, typically to provide reductions in computation time. In that sense it's a subset of concurrent computing, but typically addresses other concerns in addition to concurrency. --Allan McInnes (talk) 01:43, 13 May 2009 (UTC)
This article suggests that, somehow, various computer languages are necessary for concurrent processing. Transaction processing has been around for at least 50 years and most of the quoted languages didn't exist then. Concurrent programming is more an "environment" (or a set of requirements) rather than a paradigm or language. I don't think a computer language has any real relevance to concurrent programming and the emphasis of the article should be altered to reflect its much more generic nature. Also message passing is not the only means of program communication in concurrent computing environments and task/subtask initiation, termination and database or server interactions & synchronization and frequently rapid response much more significant. —Preceding unsigned comment added by Kdakin (talk • contribs) 07:05, 17 May 2010 (UTC)
- I'll address your points individually:
- "This article suggests that, somehow, various computer languages are necessary for concurrent processing." – Where does it suggest that?
- "Concurrent programming is more an "environment" (or a set of requirements) rather than a paradigm or language." – Could you elaborate, please? And what do you mean by "environment"?
- "I don't think a computer language has any real relevance to concurrent programming" – It definitely does. For example, languages without a formal memory model (like C) will raise many problems when you use shared memory communication; a type system might ensure certain properties, like deadlock-freedom. There is a lot of potential for a programming language to facilitate or hinder concurrent programming.
- "Also message passing is not the only means of program communication in concurrent computing environments" – Where does the article imply this?
- "[…] much more significant" – Much more significant than what?
- Adrianwn (talk) 17:21, 17 May 2010 (UTC)
After describing shared memory and message passing styles, the article states "Typically (although not always), the ... overhead ... is lower in a message passing system". ?!? Shared memory systems are generally much faster than message-passing systems because the former can bypass data copy, serialization, etc. Was this a typo? If it was intentional, some justification should be given. 22.214.171.124 (talk) 19:01, 31 July 2013 (UTC)