Copyright © 1997 - 2011 - Curt Hill Concurrent Execution An Overview for Database

Copyright © 1997 - 2011 - Curt Hill

Concurrent Execution

An Overview for Database


MultiTasking

• Multitasking is the apparent execution of programs in parallel

• This supports parallel execution usually under one or more of these names– Tasks– Processes– Threads

• This can be accomplished with a single processor or with several processors


Definitions• Process

– An executable program to the OS– Sole possession of code and variable

memory– Must communicate through the OS

• Thread– Independent execution within a process– Share code and variables within a process

• These work in Win32 and UNIX• Tasks can be either


Single Processor UniProcessing

• Single CPU, but apparent multiple tasks

• Permissive– Any system call allows the current task to

be suspended and another started

• Preemptive– A task is suspended when it makes a

system call that could require waiting– A time slice occurs


Multiple Processors MultiProcessing

• Real multiprocessing involves multiple CPUs

• Multiple CPUs can be executing different jobs

• They may also be in the same job, if it allows

• A DBMS is usually multi-threaded


Off to the Races• Most programming languages are

Sequential

• There are a number of kinds of errors that can occur when there are two simultaneously executing tasks that share anything

• When different results may be obtained by the same code and data because of time dependencies, this is called a race

Granularity• At the program level we are concerned

with instruction granularity– On uniprocessors individual instructions are

usually atomic– No guarantees of any sort with

multiprocessors

• At the database level we are concerned with transaction granularity– Since a transaction generally involves

multiple database accesses and hundreds of machine instructions even fewer guarantees



Race Example • Consider two transactions

• Transaction A has– Read row x of table y– Add 2 to field z – Write row x of table y

• Transaction B has– Read row x of table y– Add 5 to field z – Write row x of table y


Racing Form

• Read x of y• Add 2 to z• Write x of y

• Read x of y• Add 5 to z• Write x of y

There are three possible outcomes.It all depends on where a time slice

occurs.


Race Results• If transactions are serialized z will have

7 added to it

• If A starts and is interrupted, then the add of two is kept and the add of five is lost

• If B starts first and is interrupted, then the add of five is kept and the add of two is lost

• Without precautions we could end with a add of 2, 5 or 7

Query Race• This gets complicated when multiple

updates must occur as a unit

• Consider the airline reservation problem

• I want to book a flight from:• Fargo to Minneapolis• Minneapolis to Atlanta• Atlanta to Pensacola

• Each leg reservation is competing with many others and I must have them as a unit


How to solve?• At the machine instruction level there

are several techniques– Critical sections– Mutexes– Semaphores

• All of these involve some kind of lock

• Locks come in two flavors:– Shared – Exclusive


Lock Types• An exclusive lock only allows one thread

to have control– Usually used for write or update

• Any others that attempt are forced to wait

• A shared lock is usually used for reading

• Any number of items can share but one exclusive lock prevents all shared or is forced to wait until all shared locks are released



Waiting

• If a lock prohibits entry the task must wait

• Two kinds of wait:– Busy wait - spin in a loop– Idle wait - suspended until later

• This wait time keeps a multi CPU system from reaching its true potential, especially while in the dispatcher


Locked Solution

• Lock y• Read x of y• Add 2 to z• Write x of y• Unlock y

• Lock y

• Read x of y

• Add 5 to z

• Write x of y

• Unlock y

Always update z to 7 larger

Lock Granularity• In the above example an exclusive lock

was applied to the entire table

• Databases have considerable variance as to what may be lockable:

• Tables• Pages• Records• Fields

• The finer the granularity the less conflicts there will be– Thus better performance– However, much more bookkeeping



Wait Problems

• A critical section guarded by a semaphore is a special case of resource allocation

• In order for a task to complete it has to ask for and receive a resource– If it cannot, it is forced to wait

• This however allows for other problems


Deadlock

• Situation where tasks cannot get the resources they need

• Task A has resource 1 and is waiting for resource 2

• Task B has resource 2 and is waiting for resource 1

• Both are waiting for a situation that cannot be resolved


The Dining Philosophers Problem

h


The Dining Philosophers Problem

• There is a round table with five philosophers, five plates of spaghetti and five forks

• A philosopher always picks up the right fork, then the left, then eats

• If all five reach out their right hand at the same time all the forks are gone then there is a deadlock


Traffic Deadlock

Traffic Deadlock Again• Car A

– Holds resource 1, which is street in front of West street

– Wants resource 2, which is street in front of East street

• Car B – Holds resource 2, which is street in front of East

street– Wants resource 1, which is street in front of West

street

• In order to turn, each needs both• It can get much more complicated



Deadlock

• Is it a programmer problem or a DBMS problem?

• Both.


Avoiding Deadlock• A DBMS should be able to detect a

deadlock

• Usual solution is to abort transactions until something can proceed

• Ability to reclaim a resource also required

• Programmer should avoid situations that might lead to it:

• Do not wait for a resource while holding a resource

Documents

Copyright © 1997 - 2011 - Curt Hill Concurrent Execution An Overview for Database