Inherently concurrent processing will involve shared resources like memory and will lead to race conditions. A simple example would be an accumulator variable which needs to be read by all the processes running concurrently, adding some value to it and storing back the result. The race condition occurs when
Determine to Stay Serial or Go Parallel
Given that concurrent programming involves unique challenges like race conditions and deadlocks, it would be advantageous to determine whether concurrent processing of a problem provides better performance than serial processing. Speedup is the metric which can be used to make this comparison. This involves identifying the best solutions to solve the problem through serial processing and concurrent processing.
Concurrent Parallel or Distributed Processing
Reading through literature and books on concurrency and programming there are instances where terminologies are used interchangeably which sometimes cause confusion. Here are some of the terms and how I understand/use them
Concurrency and Why Application Developers Need to Know About It
“Concurrent” in simple terms is defined as more than one thing happening or done at the same time. Working on a document and at the same time communicating with a colleague through a messaging system is an example of concurrency. But how does it relate to computers and programming? In its simple model, computers have interfaces like key board, mouse, touch screen, display unit for users to interact with, network interface to connect with other computers, storage to store and retrieve data and the hardware which includes the CPU to do processing. In order to manage the interactions with the various components, computers need to do multiple things at the same time. All the simultaneous interactions with devices and the users of computers are managed by operating systems. As any OS or device driver or system call developer can attest, concurrency is a challenge they face quite often.
A Scalable Content-Addressable Network
Distributed internet scale hash table is a CAN and the concepts detailed in this paper can help in building a completely decentralized distributed system like a distributed datastore. The CAN described consists of multiple nodes and each node stores a chunk called the Zone of the entire hash table. In addition each node holds information about a small number of adjacent zones in the table. Requests for a particular key are routed by intermediate CAN nodes to the node which contains the key. The CAN described is completely scalable, fault tolerant, scalable and is implemented at the application level