Talk:Concurrent computing

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?

--70.189.73.224 15:08, 23 September 2006 (UTC)

Monitors, Mutexes, tokens and other forms of resource control are not inherently part of the concurrent paradigm. Concurrency at its core describes a series of actions that regardless of execution time will deterministically conclude (this makes no assumptions about physical hardware and is provable). For any algorithm to be in a concurrent state it has to be non blocking, e.g. no single point of execution has any relation or dependency on any other point of execution. If there is a hardware limitation causing blocking behavior the execution can be freely paused without affecting its state(it can still alter the flow by its action on resources like memory, io control, or processor control) but not block or lock any other point of execution. Future readers should ignore the comment above this as it is clearly written by someone without expertise in concurrency. — Preceding unsigned comment added by 76.88.186.107 (talk) 13:41, 30 July 2018 (UTC)

Types of concurrency

Atleast accordigng to CTM Book the three variants are

• Shared memory concurrency
• Message Passing concurrency
• Dataflow concurrency

(i.e Dataflow is an independent branch) Blufox (talk) 09:32, 1 October 2008 (UTC)

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)

Clearer definition

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 142.167.85.107 (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)?

Should this page be merged with Concurrency (computer science)? --FishSpeaker (talk) 03:15, 14 November 2008 (UTC)

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)

Merge with Parallel Computing? --Javalenok (talk) 08:08, 12 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)

Transaction processing

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)

Overhead question

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. 129.55.200.20 (talk) 19:01, 31 July 2013 (UTC)

Removed the software pipeline example

I removed the software pipeline example, because I'm not convinced it's an example of concurrency. The present article is doing its best to distinguish concurrency from parallelism (even though Pike, cited for the confusion between the two, actually connects them), and citing an obviously sequential algorithm (lex, parse, translate, assemble, link) isn't helping that cause. QVVERTYVS (hm?) 21:24, 9 January 2015 (UTC)

PCM Disambiguation

"Process Communication Model" can also refer to Taibi Kahler's Process Communication Model, a model of human communication that was used at NASA during the selection of shuttle astronauts and is now available for HR training. I'm currently researching Kahler and intend expanding his entry and adding one for his PCM.

Any objections to a disambiguation page for "Process Communication Model"? If that term is searched it currently links directly to Concurrent Computing. Aeon-lakes (talk) 02:48, 9 April 2015 (UTC)

"Process Communication Model" now redirects to Taibi Kahler. A hatnote on that page provides a link back to this page for disambiguation. A full article for 'Process Communication Model' will follow in due course. Is the disambiguation really needed? I see no mention of 'Process Communication Model' on this page. aeon-lakes 10:37, 10 April 2015 (UTC)

A search for "Process Communication Model" now leads to a disambiguation page allowing a choice between Concurrent computing and the Psychology entry on Taibi Kahler. I have removed the hatnote on that page as there is no primary article for the computing concept of that name. Will Concurrent computing link to a Process Communication Model primary article in future? If so, I suggest that it becomes "Process Communication Model (computing)" and the psychology one be entitled "Process Communication Model (psychology)". A hatnote on each page would then allow the disambiguation page to be deleted. aeon-lakes 04:38, 11 April 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Concurrent computing. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100306171307/http://codespeak.net/py/0.9.2/greenlet.html to http://codespeak.net/py/0.9.2/greenlet.html
• Added archive https://web.archive.org/web/20060128114620/http://vl.fmnet.info/concurrent/ to http://vl.fmnet.info/concurrent/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:30, 12 August 2017 (UTC)

Should BSP be added to the Model section?

Would it be appropriate for Bulk_synchronous_parallel to be added to the Models section?

46.208.236.121 (talk) 04:33, 24 May 2018 (UTC)

Concurrent transmission

I have removed this paragraph from the lead as there is no support for it in the body of the article and it seems to be discussing a different subject. ~Kvng (talk) 00:22, 14 November 2018 (UTC)

The concurrent scheduling of data transmission in Wireless network helps increase in network throughput. Use of Directional antennas and Millimeter-wave communication in WPAN gaining increased interest. Owing to properties of Directional antennas and Millimeter-wave, the probability of concurrent scheduling of non‐interfering transmissions increases, which results in an immense increase in network throughput. However, the optimum scheduling of concurrent transmission is an NP-Hard problem .

References

What does sheaf have to do with concurrent programming?

I will remove the link if no one objects. Digital27 (talk) 14:17, 14 November 2023 (UTC)