Lower degree of consistency and Lock management

Lower degree of consistency:

Most systems don’t provide consistency as outlined here. Typically they don’t hold read locks to EOT so that R->W->R dependencies isn’t precluded. Extremely primitive systems sometimes set no read locks at all rather they only set update locks so as to avoid lost update and deadlock during back-out. We have characterized these lock protocols as degree 2 as well as degree 1 consistency respectively and have studied them extensively (see ‘Granularity of locks and degrees of consistency in a shared data base’, Putzolu, Gray, Lorie and Traiger. in Modeling and Data Base Systems North Holland Publishing (1976).) I believe that the follower degrees of consistency are a bad idea, but several of my colleagues disagree. The motivation of the inferior degrees is performance. If less is locked afterwards less computation and storage is consumed. Moreover if less is locked concurrency is increased since fewer conflicts appear. (Note that reducing the number of explicit locks set motivates the granularity lock scheme of the next section.)

Lock granularity:

An important issue that occur in the design of a system is the choice of lockable units (that is the data aggregates which are atomically locked to insure consistency.) illustration of lockable units is files, areas, individual records, field values and intervals of field values.

The choice of lockable units presents a trade-off among concurrency and overhead which is related to the size or granularity of the units themselves. Alternatively concurrency is increased if a fine lockable unit (for illustration a record or field) is chosen. Such unit is appropriate for a ‘simple’ transaction that accesses few records. Alternatively a fine unit of locking would be costly for a ‘complex’ transaction that accesses many records. Such a transaction would have to set as well as reset many locks incurring the computational overhead of many invocations of the lock manager and the storage overhead of representing many locks. A coarse lockable unit for illustration a file is probably convenient for a transaction that accesses many records. Nevertheless such a coarse unit discriminates against transactions that only want to lock one member of the file. From this discussion it tracks that it would be desirable to have lockable units of different granularities coexisting in the same system.

The following presents a lock protocol pleasing these requirements and discusses the related implementation issues of granting, scheduling and converting lock requests.

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.

©TutorsGlobe All rights reserved 2022-2023.