Ad

Sunday, September 20, 2015

Deadlock Detection & Recovery

Deadlock Detection & Recovery

Tuesday, September 15, 2015

Bankers algorithm program

Banker's Algorithm
Goal:-  C program For Banker's Algorithm.
Method:-  Simple Rules Of Banker Algorithm.
Explanation:-  Banker's Algorithm is a deadlock avoidance algorithm that checks for safe or unsafe state of a System after allocating resources to a process.
When a new process enters into system ,it must declare maximum no. of instances of each resource  that it may need.After requesting operating system run banker's algorithm to check whether after allocating requested resources,system goes into deadlock state or not. If yes then it will deny the request of resources made by process else it allocate resources to that process.
No. of requested resources (instances of each resource) may not exceed no. of available resources in operating system and when a process completes it must release all the requested and already allocated resources.
For implementing Banker's algorithm we should have pre-knowledge about three things:-
  • How many instance of each resource a process could request. (Max)
  • How many instance of each resource is already allocated to that process(Allocated)
  • How many instance of each resource is already available(Available).
We can calculate need of each process from above information:-
               Need=Max - Allocated.
If need<=available then request will be accepted otherwise it is denied and it will check for next process in waiting queue.(See Life Cycle Of a Process)
Safe or Unsafe State:- A system is in Safe state if its all process finish its execution or if any process is unable to aquire its all requested resources then system will be in Unsafe state. 






Example:-  To understand banker's algorithm,we consider a system with four processes P1 through P4 and three resource type A,B and C.Resource type has 10 instances,B has 5 instances and C has total 7 instances.
Current Scenario:-

Table-1
Need[P2] < Available..So P2 we allocate resources to P2. After Completion of P2 ,Scenario...

Table-2
Now Need[P4] < Available so P4 will complete its execution .After that--
Table-3
So P1 will execute and after that P3 will take resources.
  Safe Sequence is :-   P2 , P4, P1,P3 (we can obtain one more sequence if we allocate resources to P3 before P1 .)
Program:-
#include<stdio.h>
#include<conio.h>
   int process,resource,i,j;
  int avail[10],max[10][10],allot[10][10],need[10][10],completed[10];
void get_details()
   {
   int instanc;
   //count,k variables are taken for counting purpose
   printf("\n\t Enter No. of Process:-\n");
  printf("\t\t");
 scanf("%d",&process);                           //Entering No. of Processes
 printf("\n\tEnter No. of Resources:-\n");
   printf("\t\t");
   scanf("%d",&resource);                       //No. of Resources

   printf("\n\tEnter No. of Available Instances\n");
   for(i=0;i<resource;i++)
    {
     printf("\t\t");
     scanf("%d",&instanc);
     avail[i]=instanc;                        // Storing Available instances
    }

 printf("\n\tEnter Maximum No. of instances of resources that a Process need:\n");
 for(i=0;i<process;i++)
     {
      printf("\n\t For P[%d]",i);
for(j=0;j<resource;j++)
{
   printf("\t");
    scanf("%d",&instanc);
   max[i][j]=instanc;
}
     }
    printf("\n\t Enter no. of instances already allocated to process of a resource:\n");
     for(i=0;i<process;i++)
     {
printf("\n\t For P[%d]\t",i);
for(j=0;j<resource;j++)
{
   printf("\t\t");
   scanf("%d",&instanc);
   allot[i][j]=instanc;
   need[i][j]=max[i][j]-allot[i][j];      //calculating Need of each process
}
   }


   }
int is_safe()
   {
   int count1=0,count2=0,k=0;
   int avail2[10];
   for(i=0;i<process;i++)
      { completed[i]=0;
       } //Setting Flag for uncompleted Process
       for(i=0;i<resource;i++)
      { avail2[i]=avail[i];
       }
    printf("\n\t Safe Sequence is:- \t");
    while(count1!=process)
    {
    count2=count1;
    for(i=0;i<process;i++)
     {
       for(j=0;j<resource;j++)
       {
   if(need[i][j]<=avail2[j])
     {
k++;
     }//if
}//for
if(k==resource && completed[i]==0 )
{
 printf("P[%d]\t",i);
  completed[i]=1;
  for(j=0;j<resource;j++)
    {
      avail2[j]=avail2[j]+allot[i][j];
    }//for
    count1++;
}//if
k=0;
       }//for
if(count1==count2)
{
printf("\t\t Stop ..After this.....Deadlock \n");
return 0;
//break;
       }//if
     }//while
 return 1;
}
//if return value=1 then less than or equal
int lre(int first[],int second[])
    {
    int i=0;
    for(i=0;i<resource;i++)
{
if(first[i]>second[i]){return 0;}
}
    return 1;
    }
void modify(int first[],int second[],char op)
   {
   int i=0;
   for(i=0;i<resource;i++)
      {
      if(op=='+')
first[i]=first[i]+second[i];
      else
first[i]=first[i]-second[i];
      }
   }
void print(int a[10][10])
   {
 for(i=0;i<process;i++)
     {
     for(j=0;j<resource;j++)
 {
 printf(" %d ",a[i][j]);
 }
      printf("\n");
      }

   }
void bankers()
  {
   int req[10],i=0,pid;
   printf("\nenter requesting process number:");
   scanf("%d",&pid);
   printf("\nenter request vector:");
   for(i=0;i<resource;i++)
      {
      scanf("%d",&req[i]);
      }
    if(lre(req,need[pid]))
       {
       if(lre(req,avail))
 {
 modify(avail,req,'-');
 modify(allot[pid],req,'+');
 modify(need[pid],req,'-');
 printf("\nallocation:\n");
 print(allot);
 printf("\nneed:\n");
 print(need);
 if(is_safe())
   {
   printf("Requested Resources are allocated for P[%d]",pid);
   }
 else
   {
 modify(avail,req,'+');
 modify(allot[pid],req,'-');
 modify(need[pid],req,'+');
 printf("DEADLOCK COMES->Requested Resources are NOT allocated for P[%d]",pid);
   }
 }
       else
{
printf("\nP[%d] should wait -> no available resources",pid);
}
       }
    else
{
printf("\nsorry!!!error!!!process has requested more than its max claim");
}
  }

void main()
 {
   clrscr();
   get_details();
   if(is_safe())
   {
   bankers();
   }
   getch();
   }




Wednesday, September 9, 2015

Atomic Transactions


Atomic Transactions
Download here
·               System Model
·               Log-based Recovery
·               Checkpoints
·               Concurrent Atomic Transactions

System Model
·         Assures that operations happen as a single logical unit of work, in its entirety, or not at all 
·         Related to field of database systems 
·         Challenge is assuring atomicity  despite computer system failures 
·         Transaction - collection of instructions or operations that performs single logical function 
·         Here we are concerned with changes to stable storage – disk 
·         Transaction is series of read and write operations 
·         Terminated by commit  (transaction successful) or abort (transaction failed) operation 
·         Aborted transaction must be rolled back to undo any changes it performed
Types of Storage Media
·         Volatile storage – information stored here does not survive system crashes 
o   Example:  main memory, cache 
·         Nonvolatile storage – Information usually survives crashes 
o   Example:  disk and tape 
·         Stable storage – Information never lost 
o   Not actually possible, so approximated via replication or RAID to devices with independent failure modes
·         Goal is to assure transaction atomicity where failures cause loss of information on volatile storage
Log-Based Recovery
·         Record to stable storage information about all modifications by a transaction
·         Most common is write-ahead logging
·         Log on stable storage, each log record describes single transaction write operation, including
o   Transaction name
o   Data item name
o   Old value
o   New value
·         <Ti starts> written to log when transaction Ti starts
·         <Ti commits> written when Ti commits
·         Log entry must reach stable storage before operation on data occurs
Log-Based Recovery Algorithm
·         Using the log, system can handle any volatile memory errors
o   Undo(Ti) restores value of all data updated by Ti
o   Redo(Ti) sets values of all data in transaction Ti to new values
·         Undo(Ti) and redo(Ti) must be idempotent
o   Multiple executions must have the same result as one execution
·         If system fails, restore state of all updated data via log
o    If log contains <Ti starts> without <Ti commits>, undo(Ti)
o    If log contains <Ti starts> and <Ti commits>, redo(Ti) 
Checkpoints 
·         Log could become long, and recovery could take long->Checkpoints shorten log and recovery time.
·         Output a log record <checkpoint> to the log on stable storage
·         Now recovery only includes Ti, such that Ti started executing before the most recent checkpoint, and all transactions after Ti All other transactions already on stable storage 
Concurrent Transactions 
·         Must be equivalent to serial execution – serializability 
·         Could perform all transactions in critical section
·         Inefficient, too restrictive
·         Concurrency-control algorithms provide serializability 
Serializability
·         Consider two data items A and B
·         Consider Transactions T0 and T1
·         Execute T0, T1 atomically
·         Execution sequence called schedule
·         Atomically executed transaction order called serial schedule
·         For N transactions, there are N! valid serial schedules
·         Schedule 1: T0 then T1



Nonserial Schedule 
·         Nonserial schedule allows overlapped execute
·         Resulting execution not necessarily incorrect
·         Consider schedule S, operations Oi, Oj
·         Conflict if access same data item, with at least one write
·         If Oi, Oj consecutive and operations of different transactions & Oi and Oj don’t conflict
·         Then S’ with swapped order Oj Oi equivalent to S
·         If S can become S’ via swapping nonconflicting operations.
·         S is conflict serializable 
·        Schedule 2: Concurrent Serializable Schedule



Locking Protocol
·         Ensure serializability by associating lock with each data item
·         Follow locking protocol for access control
·         Locks
o   Shared – Ti has shared-mode lock (S) on item Q, Ti can read Q but not write Q
o   Exclusive – Ti has exclusive-mode lock (X) on Q, Ti can read and write Q
·         Require every transaction on item Q acquire appropriate lock
·         If lock already held, new request may have to wait
·         Similar to readers-writers algorithm
Two-phase Locking Protocol
·         Generally ensures conflict serializability
·         Each transaction issues lock and unlock requests in two phases
o   Growing – obtaining locks
o   Shrinking – releasing locks
·         Does not prevent deadlock
Timestamp-based Protocols
·         Select order among transactions in advance – timestamp-ordering
·         Transaction Ti associated with timestamp TS(Ti) before Ti starts
o   TS(Ti) < TS(Tj) if Ti entered system before Tj 
o   TS can be generated from system clock or as logical counter incremented at each entry of transaction
·         Timestamps determine serializability order
o   If TS(Ti) < TS(Tj), system must ensure produced schedule equivalent to serial schedule where Ti appears before Tj 
Timestamp-based Protocol Implementation
·         Data item Q gets two timestamps
o   W-timestamp(Q) – largest timestamp of any transaction that executed write(Q) successfully
o   R-timestamp(Q) – largest timestamp of successful read(Q)
o   Updated whenever read(Q) or write(Q) executed
·         Timestamp-ordering protocol assures any conflicting read and write executed in timestamp order
·         Suppose Ti executes read(Q)
o   If TS(Ti) < W-timestamp(Q), Ti needs to read value of Q that was already overwritten
§  read operation rejected and Ti rolled back
o   If TS(Ti) ≥ W-timestamp(Q)
§  read executed, R-timestamp(Q) set to max(R-timestamp(Q), TS(Ti))

Timestamp-ordering Protocol
·         Suppose Ti executes write(Q)
o   If TS(Ti) < R-timestamp(Q), value Q produced by Ti was needed previously and Ti assumed it would never be produced
§  Write operation rejected, Ti rolled back
o   If TS(Ti) < W-tiimestamp(Q), Ti attempting to write obsolete value of Q
§  Write operation rejected and Ti rolled back
o   Otherwise, write executed
·         Any rolled back transaction Ti is assigned new timestamp and restarted
·         Algorithm ensures conflict serializability and freedom from deadlock
Schedule Possible Under Timestamp Protocol