Scribd
Upload
6 views38 pages

Concurency Models

The document discusses concurrency in modern programming, highlighting its necessity in various applications such as web services and mobile apps. It outlines three common models for concurrent programming: shared memory, message passing, and the Actor model, detailing their mechanisms and examples. Additionally, it addresses potential concurrency issues and introduces multiversion two-phase locking as a solution for managing data consistency.

Uploaded by

nambingaemmanuel10
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views38 pages

Concurency Models

The document discusses concurrency in modern programming, highlighting its necessity in various applications such as web services and mobile apps. It outlines three common models for concurrent programming: shared memory, message passing, and the Actor model, detailing their mechanisms and examples. Additionally, it addresses potential concurrency issues and introduces multiversion two-phase locking as a solution for managing data consistency.

Uploaded by

nambingaemmanuel10
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

Concurency Models

By Ms Ndinelago Nashandi
Concurrency

Concurrency means multiple computations are happening at the


same time. Concurrency is everywhere in modern programming,
whether we like it or not:
▪ Multiple computers in a network
▪ Multiple applications running on one computer
▪ Multiple processors in a computer (today, often multiple processor
cores on a single chip)
Concurrency cont…

• In fact, concurrency is essential in modern programming:


• Web sites must handle multiple simultaneous users.

• Mobile apps need to do some of their processing on servers (“in the cloud”).

• Graphical user interfaces almost always require background work that does
not interrupt the user. For example, Eclipse compiles your Java code while
you’re still editing it.
• There are three common models for concurrent
Two Models for programming: shared memory ,message
Concurrent passing and Actor Models.

Programming • Shared memory. In the shared memory model


of concurrency, concurrent modules interact by
reading and writing shared objects in memory.
shared-memory model
• Other examples of the shared-memory model:
• A and B might be two processors (or processor cores) in the same
computer, sharing the same physical memory.

• A and B might be two programs running on the same computer, sharing


a common filesystem with files they can read and write.

• A and B might be two threads in the same Java program (we’ll explain
what a thread is below), sharing the same Java objects.
Message passing

• In the message-passing model,

concurrent modules interact by sending messages to each other


through a communication channel. Modules send off messages,
and incoming messages to each module are queued up for
handling.
Examples include:
• A and B might be two computers in a network, communicating by network connections.

• A and B might be a web browser and a web server – A opens a connection to B, asks for a
web page, and B sends the web page data back to A.

• A and B might be an instant messaging client and server.

• A and B might be two programs running on the same computer whose input and output
have been connected by a pipe, like ls | grep typed into a command prompt.
Actor Model

• The actor model has its theoretical roots in concurrency modelling [Hew73] and message
passing concepts [Hoa78]. . It defines some general set of guidelines how system
components should interact in concurrent computational environment.

• An Actor in Actor Model is an fundamental unit of computation, it can perform below


actions.
• Create another Actor
• Send a message
• Designate how to handle the next message
Actor
Model
• Actors are light
weight and it is
very easy to
create millions of
them as they take
fewer resources
than Threads
Actor Model Cont…

• As showed in the diagram(previous page), an Actor has it own private


state and a mail box (similar to message queue). Mailbox contains
the message which the Actor has got from others, message here
means Simple Immutable Data structures. Messages are processed in
FIFO order.
Actor model cont…

• Actor decided on how to handle the next message based on it’s


current private state, for example if an Actor is keeping the count of a
particular value(X=10) and received a message to add two to the
value, it will update it’s private state and keep X=12. X=12 will be
available for the next message in queue.

• Actors are isolated in nature and they don’t share memory


Actor model cont…

• Actor’s private state can only be changed by processing a message, it can


handle only one message at a time and they work asynchronously, it means
one Actor never waits for a response from anther Actor.

• Actors interact with each other through messages only. It can only interacts
with Actors whose address it has (same like our phonebook)
• Actors which it has created (hence already know the address of child actors)

• Extract address for messages it receives


Actor model cont…
• In distributed scenario it possible that Actors are on different machines hence they
communicate to address with messages, an address can be a local address or a remote
address.

• Using Actor model one can create Self Healing System or Fault tolerant systems. The
First Actor created we can call it as master, it creates multiple other actors which are like
supervisor to the master. If a actor dies or not responsive, it’s supervisor can primary
take below calls to make it self healing system.
• Restart
• Redirect the message to another Actor
Actor Model Cont…

• Pros of Actor Model


• Easy to scale
• Fault Tolerant
• No shared state

• Cons of Actor Model


• Mailbox can overflow
• Susceptible to deadlocks
Concurrency
control
mechanisms
Potential problems of Concurrency
• Lost Updates occur when multiple transactions select the same row and update the row based
on the value selected

• Uncommitted dependency issues occur when the second transaction selects a row which is
updated by another transaction (dirty read)

• Non-Repeatable Read occurs when a second transaction is trying to access the same row
several times and reads different data each time.

• Incorrect Summary issue occurs when one transaction takes summary over the value of all
the instances of a repeated data-item, and second transaction update few instances of that
specific data-item. In that situation, the resulting summary does not reflect a correct result.
Multiversion 2 phase locking:
Each successful write results in the creation of a new
version of the data item written. Timestamps are
used to label the versions. When a read(X) operation
is issued, select an appropriate version of X based on
the timestamp of the transaction.

You might also like