Assignment Help - homework help

  Lock management pragmatics and Lock management

Lock management pragmatics:

Therefore far we have discussed when to lock (lock before access and hold locks to commit point) and why to lock (to guarantee consistency and to make recovery possible without cascading transaction backup,) as well as what to lock (lock at a granularity that balances concurrency against instruction overhead in setting locks.) The remainder of this section will confer issues associated with how to implement a lock manager.

Lock manager interface:

This is a uncomplicated version of the System R lock manager.

Lock actions:

Lock manager has two essential calls:

LOCK <lock>, <mode>, <class>, <control> where <lock> is the resource name (in System R for example an eight byte name). <mode> is one of the lock modes { S | X | SIX | IX | IS }. <class> is a notion explained below. <control> can be either WAIT in which case the call is synchronous as well as waits until the request is granted or is cancelled by the deadlock detector, or <control> can be TEST in which case the request is cancelled if it can’t be granted immediately.

UNLOCK <lock>, <class> releases the specified lock in the specified class. If the <lock> isn’t specified all locks held in the specified class are released.

Lock names:

The association among lock names and objects is purely a convention. Lock administrator associates no semantics with names. In general the first byte is reserved for the subsystem (component) identifier as well as the remaining seven bytes name the object.

For illustration data manager might use bytes (2... 4) for the file name as well as bytes (5... 7) used for the record name in constructing names for record locks.

Since there are several locks one only allocates those with non-null queue headers. (That is free locks occupy no space.) Setting 1 lock comprises of hashing the lock name into a table. If the header before now exists the request enqueues on it or else the request allocates the lock header and places it in the hash table. When the queue of a lock turn into empty the header is de-allocated (by the unlock operation).

Lock classes:

Many operations obtain a set of locks. If the operation is thriving the locks must be retained. If the operation is unsuccessful or when the operation commits, the locks must be released. In order to evade double bookkeeping the lock manager permits users to name sets of locks (in the new DBTG proposal these are called keep lists in IMS program isolation these are called *Q class locks).

For every lock held by each process lock manager keeps a list of <class, count> pairs. Every lock request for a class increments the count for that class. All unlock request decrements the count. When each counts for all the lock's classes are zero then the lock is not held by the process.

Latches:

Lock manager requires a serialization mechanism to perform its function (example- inserting elements in a queue or hash chain). It does this by executing a lower level primitive called a latch. Latches are semaphores. They offer a cheap serialization mechanism without providing the expensive features like deadlock detection, class tracking, as well as modes of sharing (beyond S or X). They are utilized by lock manager and by other performance critical managers (notably buffer manager and log manager).

Performance of Lock Manager:

Lock administrator is about 3300 lines of (PL/l like) source code. It depends crucially on the Compare and Swap logic provided by the multiprocessor feature of System 370. It encompasses three percent of the code and about ten percent of the instruction execution of a program in System R (this may vary a great deal.)

A lock-unlock pair currently costs 350 instructions however if these notes are ever finished, this will be abridged to 120 instructions (this should reduce its slice of the execution pie.) A latch-unlatch pair needs 10 instructions (they expand in-line). (Initially they required 120 instructions however a careful redesign improved this dramatically.)

Latest technology based Operating System Online Tutoring Assistance

Tutors, at the www.tutorsglobe.com, take pledge to provide full satisfaction and assurance in Operating System help via online tutoring. Students are getting 100% satisfaction by online tutors across the globe. Here you can get homework help for Operating System, project ideas and tutorials. We provide email based Operating System help. You can join us to ask queries 24x7 with live, experienced and qualified online tutors specialized in Operating System. Through Online Tutoring, you would be able to complete your homework or assignments at your home. Tutors at the TutorsGlobe are committed to provide the best quality online tutoring assistance for Operating System Homework help and assignment help services. They use their experience, as they have solved thousands of the Operating System assignments, which may help you to solve your complex issues of Operating System. TutorsGlobe assure for the best quality compliance to your homework. Compromise with quality is not in our dictionary. If we feel that we are not able to provide the homework help as per the deadline or given instruction by the student, we refund the money of the student without any delay.
Home | Company Overview | Services | Discover Q&A | Sitemap | Contact Us | T & C | Refund Policy | Copyright Policy | Blog | Q&A | Directory

©TutorsGlobe All rights reserved 2022-2023.