Chapter 6.4: Process Synchronization Part 4

6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Module 6: Process Synchronization Lecture 6.1 Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Lecture 6.2: Semaphores Lecture 6.3 Classic Problems of Synchronization Monitors Synchronization Examples Lecture 6.4 Atomic Transactions

6.3 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Synchronization in Linux We recall that prior to version 2.6, Linux was a non-preemptive kernel. Newer versions of the Linux kernel are preemptive. This means a task can be preempted when running in kernel mode. Now, we know that the Linux kernel uses spinlocks and semaphores for locking in the kernel. Recall: Spinlocks – a type of semaphore that causes continual looping executing a busy waiting execution.  It may be costly because the CPU could be busy doing other tasks.  Might be okay, however, in that there is no context switching involved and when the locks are expected to be held for only a very short time, spinlocks may be the way to go.  Often employed on multiprocessor systems because one thread can wait (spin) on one processor while another process executes its critical section on another processor. Semaphores – merely an integer variable itself (usually an integer) that can be accessed controlled only via two atomic operations: wait() and signal().

6.4 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Synchronization in Linux – more As we are aware, in symmetric multiprocessors (SMP), spinlocks will work well if critical section execution is quick. For single processor machines, the mechanism used is to simply enable / disable kernel pre-emption. In summary: in single processors, we disable / enable preemption, while in multiple processor machines, we use spinlocks (acquire and release the spin lock). Now, how does Linux implement the preemption process? Linux employs two system calls: preempt_disable() and preempt_enable().

6.5 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Synchronization in Linux – more Pre-empting the kernel is not always a simple task; at times it may not be safe.  There may be a process executing in kernel mode currently holding lock(s). So, do we really want to preempt such processes??? To address this, each task in the system has what is called a ‘thread-info’ structure that contains an integer counter, preempt_count. This counter indicates the number of locks held by the task. Any time a kernel mode task is holding one or more locks, (lock > 0), then preempting cannot be done.. So only when this count becomes zero (that is, the executing task releases all locks), then a kernel process can be interrupted via the system calls. As we recall, spinlocks and kernel preemption/non-preemption are acceptable approaches when a lock is held for a short time. If a lock must be held for longer periods, a semaphore is used and typically a process blocks.

6.6 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts 6.9 Atomic Transactions Goal is to ensure critical sections are executed atomically by using mutual exclusion mechanisms.  Motivation: execute critical section totally or not at all. Long time focus in data base systems where one is not allowed to read, say, financial data, when the file / database is undergoing updating by another process. Much research has taken place in the database arena. Thinking: apply this research to operating systems too. These are the ideas behind atomic transactions. The transaction must execution to completion.

6.7 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts The System Model Transaction – a series of instructions that must run from beginning to end (atomic execution) – considered a ‘single logical function.’ Here, we are reading and writing – terminated by ‘commit’ or ‘abort.’ Commit implies that transaction has completed a successful execution. Abort implies that the transaction terminated due to logical error or system failure. Now, an aborted transaction may have updated data and this data might not be in the correct ‘state’ when the transaction terminated abnormally. Thus, we must undertake some kind of roll back or restore to get the data back to its previous stable / reliable state.

6.8 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts The System Model – more; Devices So we must talk about device properties used to store data that might be involved in some kind of rollback. Volatile Storage – usually does not survive a system crash (central memory and cache) Nonvolatile Storage – data usually survives crashes (disks, magnetic tapes, …) Stable Storage - Information never lost. Here we  replicate information in ‘non-volatile storage caches’ (generally disk) with independent failure models and to  update the information in a controlled manner. (later chapters)

6.9 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts The System Model – more; the Log We also have a Log. Before a write() is ultimately executed, all ‘log’ info must be written to stable storage. Clearly, this incurs a very serious performance penalty!! Additional ‘Writes’ plus additional storage are needed for the log, etc. But where vitally important, such as in secure environments, financial environments, and more, this performance penalty is worth the price. In general terms, by using the log, the system is able to recover from a failure and recover from a partial update. Two algorithms are needed: An undo() – restores values of data prior to Transaction A redo() – sets values of data to new values. Both old values and new values must have been loaded into the log for these two algorithms to be successful. Naturally, failure can occur during recovery. So this process must be idempotent (yield same results if executed repeatedly).

6.10 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Checkpoints in Logs Here again, consider what we have: we have a log and the log is used to determine which transactions need to be undone and/or redone. It would first appear that we might conceivably have to go through the entire log to determine a set of transactions that need reconsideration. Major Disadvantages: Search process takes time. Recovery takes lots of time We can save time by undertaking ‘checkpoints.’ Essentially, in addition to the write-ahead logging, the system performs periodic checkpoints. Process is: Output all log records currently residing in volatile storage (PM) onto stable memory Output all modified data residing in volatile storage to the stable storage Output a log record onto stable storage.

6.11 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Checkpoints The process of establishing checkpoints in the log helps to shorten the recovery time, and it makes sense If transaction T1 is committed prior to the checkpoint, T1 commit record is in log. Here, any modifications made by T1 must have already been written to stable storage either prior to the checkpoint or as part of the checkpoint itself. In recovery, then, there is no need for a redo on the transaction. So, a recovery routine now only examines the log to determine the most recent transaction that started into execution before the most recent checkpoint took place. Does so by searching log backward to find first record and then finding the that follows it. So the redo and undo only need to be accommodated on this transaction and any others that started after.

6.12 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Log-Based Recovery To enable atomicity: Record on stable storage information describing all modifications made by transaction to data it has accessed. This method is referred to as write-ahead logging. (this is not new) System maintains a data structure called a log. Log itself consists of records describing transaction particulars:  Transaction name – unique name of trans that performed the write operation  Data item name – unique name of the data item written  Old value: value prior to the write  New value: value that data item should have after the write. Process: Prior to transaction execution, original record written to log After every ‘write’ a new record is written. Upon completion, a is written to the log.

6.13 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Summarizing This chapter was all about working with sequential processes that must share data. Of course, mutual exclusion and synchronization must be ensured. Critical Sections can be accessed by only one process at a time. Different approaches were presented to deal with this phenomenon. Main disadvantage of user-coded solutions is they usually require busy waiting. Semaphores overcome this and can be used with various schemes especially if there is hardware support for atomic instructions. Classic Problems: There is a large class of concurrency-related problems addressed by the classic bounded-buffer problem, the readers-writers problem, and the dining-philosopher problem. Monitors provide a synchronization mechanism by using an abstract data type (ADT). Condition variables provide a method by which a monitor procedure can provide additional constraints and block a process’ execution until the process is signaled to continue. We looked at Linux and discussed logs with checkpoints for recovery.

End of Chapter 6 Part 3