Lock (computer science)

Under a lock or locking (English for lock or locks) are understood in the computer science disabling of access to a resource. Such lock allows exclusive access of a process to a resource, that is, with the guarantee that no other process is reading or modified as long as the lock is this resource.

Locking is often used for process synchronization, and in file and database systems at atomic and consistent read and write requests to ensure.

• 2.1 Starvation / Starving
• 2.2 deadlock 2.2.1 Example

Locking types

Want a process exclusive access to a resource, it must (eg, a locking manager ) request a lock to an administrative process. To view the requested resource does not completely block, there are two basic types of locks:

Read lock

Write lock

Lock release

Is the process that has requested a lock finished, he must unlock it. Processes that could not be accessed due to a lock on a resource must wait and line up in a queue. There are several ways how this queue is implemented, for example, priority control, FIFO control, etc.

Starvation / Starving

Where a process not a lock back on, so may have to wait indefinitely for other processes that share. These processes " starve " (English starve ) thus.

Deadlock

Setting a lock can cause deadlocks, namely when two processes are waiting on each other to release the locked resource from each other.

Example

There were ( as resources ) a bicycle and a map. Two bike messengers to deliver each parcel and need to (respectively) bicycle and map. The courier A can reserve the bike, the courier B the map. You are now in deadlock since both are waiting for the resource of each other ( for all eternity ).

Hierarchical locking

When hierarchical locking resources into larger logical units are combined. It is now possible to lock the entire logical unit. This brings in a performance gain, since so not all elements of the unit must be locked and monitored separately. The right choice of the granularity of the logical units is of great importance.

Hierarchical Locking found mainly in database systems application. It may, for example, a data field, a record, a file, or the entire database will be locked. The ' optimal ' method arises, depending on the type of database, the frequency of changes and the number of concurrent users.

Multi -Locking

Multi -Locking belongs to pessimistic locking, and allows for a deadlock - free programming. When MultiLock the locks to be reserved at the beginning of the synchronization block and form a MultiLock. In MULTILOCKS no deadlocks can occur because a MultiLock is started only when all needed locks are available. During the execution of MultiLock no new locks can be used. However, the individual to MultiLock belonging Locks can be shared and used in other MULTILOCKS.

Implementation

The central aspect of Locks is the ability to create a process that can be precisely not " serviced " to have to wait until the lock is free - the equivalent of warte_bis function that will be used in the pseudo code below. The wait for a condition is basically in two ways possible:

• The first possibility is the reaction using the process scheduler ( ie the operating system or runtime environment, see timeshare ): The scheduler knows the lock and includes the process as long as no CPU time, until the lock is free. This is generally only possible when the lock mechanism is provided by the operating system (or the runtime ), because only then the scheduler can know the lock and its current state. Alternatively, the runtime environment to support a monitor concept in which this (wait ended on the condition variable ) by the functions wait ( on a condition variable ) and notify is implemented - the condition is then tested in a critical section of the monitor. The implementation of warte_bis would be possible as follows:

Warte_bis function (parameter condition) {         while (not condition) wait (); / / At each notify the condition is checked again     } This implies that is always called when changing the variable to which the condition refers notify, so that the condition is checked again. The second possibility is the reaction as spinlock: the process checks in a loop continuously if the lock is free, and only then continues. This is also possible without the support of the scheduler, but has the disadvantage that the process consumes CPU time while waiting ( "active waiting" or "Busy Waiting" ). If the operating system (or the runtime ) provides a way to a process for a predetermined period of " sleep " to let (sleep ), so that is not quite as bad as it is used only periodically consumes some CPU time to get the lock to Check ( also referred to as slow or busy waiting lazy polling). Not the operating system offers this possibility but, as the process consumes while waiting the full computing power of the system and thus slows down other running processes. The implementation of warte_bis would be with the possibility to sleep similar to above, with the only difference that the condition is tested at regular intervals, and not (only) when changing the variables in question:

Warte_bis function (parameter condition) {         while (not condition) sleep (1 second); / / The condition is checked once per second     } Locking is easy to implement if the end "Set the blockage if it is free at the moment " there is an atomic statement. If, however, between the audit, whether the lock is not busy, and its occupancy, a second process also can consider as they decide that the lock is to be set and now " belongs to them ". The same applies in particular to multiple threads of a process.

Example

The changes of process 2 are thus overwritten by process 1 and lost. Such errors are sometimes difficult to reproduce because they occur randomly.

Both amendments are contained in the resource.

A anschaulicheres example could be an incorrectly implemented ATM:

New status: 150 € wrong!

New status: 50 € right!