LOCK

This article or section requires a revision. Details are indicated on the discussion side. Please to improve it and removes afterwards this marking helps.

A LOCK (English. for barrier) a concept is for process synchronisation and/or in computer science. to the realization of mutual exclusion (S. Mutex) with concurrent processes (and/or. Threads). A LOCK can be possessed at the same time in each case by a process - another process tries to take the LOCK in possession, while it is assigned already „“, then must it wait, until the LOCK becomes again free. In this way monitors can be implemented.

Simple LOCKs know only two conditions, „freely “and „assigned “, and are thus the same as semaphores of size 1. An example implementation of a LOCK in object-oriented pseudo code:

Class LOCK {   Variable one  vergeben= no;

    Function get () {       if assign then warte_bis (do not assign);
        vergeben=;
    }    Function release () {       vergeben= no; //f ührt if necessary to the fact that warte_bis one breaks off.
    }}

With the fact it is to be noted that that must be assigned atomic access to the variable that thus several processes cannot access at the same time. That is to that extent problematic, this requires again a courage ex mechanism, if the run time system does not guarantee the atomic airty.

A further critical point is the function warte_bis: It presupposes that the run time system is able, a process (and/or. ) for a condition wait to let, and determine knows a Thread, when the condition occurs. See in addition the section implementation further below.

Beside the simple LOCKs above all READ Write LOCKs so mentioned are used, in order to regulate the reading and write access on data.

internally

a counter for the read access and a flag for the write access administers READ Write LOCK a READ Write LOCK. The LOCK ensures now for the fact that as many as desired processes can read at the same time, but never two processes write at the same time, and also no process reads during another writes and in reverse. If a process wants to thus read, it must wait, if straight is written. If a process wants to write, it must wait, if straight is read or written. READ Write LOCKs can be implemented with the help of simple LOCKs or with semaphores.

Here an example implementation for a READ Write LOCK in object-oriented pseudo code:

Class ReadWriteLock {  Variable lese_zähler= 0;
   Variable one  schreibe_flagge= no;

   Function hole_lesen () {     if schreibe_flagge then warte_bis (not schreibe_flagge);
      lese_zähler= more lese_zähler + 1;
   }   Function hole_schreiben () {      if (schreibe_flagge or more lese_zähler  > 0)           then warte_bis ( not schreibe_flagge and more lese_zähler == 0);

       schreibe_flagge=;
   }   Function freigeben_lesen () {      lese_zähler= more lese_zähler - 1; //beendet if necessary. warte_bis  }   Function freigeben_schreiben () {      schreibe_flagge= no; //beendet if necessary. warte_bis  } }

implementation of LOCKs

the central aspect of LOCKs is the ability to let a process, which cannot become “served” straight, wait so long until the LOCK corresponds freely to actual the function warte_bis, which was used above in the pseudo code. Waiting for a condition is in principle possible in two kinds:

• The first possibility is the conversion with the help of the scheduler (thus the operating system and/or. to the run time environment, see Time sharing): The scheduler knows the LOCK and assigns to the process no computing time until the LOCK is free. That is possible generally only if the LOCK mechanism of the operating system (and/or. ) one makes available to the run time environment, because only then the scheduler can know the LOCK and its current condition. Alternatively the run time environment also a monitor - concept to support, in which this is converted by the functions WAIT (on a conditional variable) and notify (WAIT on the conditional variable terminates) - knows the condition in a critical code segment of the monitor is then examined. The conversion of warte_bis would be then as follows possible:

   Function warte_bis ( parameter condition) {      so long ( not condition) WAIT (); // with everyone notify is again examined the condition  }

Presupposes that when changing the variables, to which the condition refers notify it is always called, so that the condition is again examined.

• The second possibility is the conversion as spin LOCK: the process constantly examines in a loop, whether the LOCK is free, and continues only then. This is possible also without support of the scheduler, has however the disadvantage that the process uses computing time, while it waits („active waiting “and/or. „Busy Waiting “). If the operating system (and/or. the run time environment) a possibility offers, a process for a given time „sleeps “to leave (sleep), then is that not completely so badly, since only in regular intervals something computing time is used, in order the LOCK to examine (one speaks also of slow busy waiting or lazy polling). If the operating system does not offer this possibility however, then the process stresses the full arithmetic performance of the system during waiting and brakes thereby different current processes out. The conversion of warte_bis would be similar with the possibility to sleep as above, only with the difference that the condition in regular intervals is examined, do not change and (only) if the variables concerned:

   Function warte_bis ( parameter condition) {      so long ( not condition) sleep (1 second); // the condition is examined once per second  }

example

the changes of process 2 thus by process 1 is overwritten and is lost. Such errors are difficult sometimes to reproduce, since they arise coincidentally.

both changes are contained in resources.