Smartphone Operating System (779883), страница 29
Текст из файла (страница 29)
These facilities need the same ‘translation’abstraction as sockets: the movement of data between sender and receiverassumes that the receiver can read what the sender has written. Issues ofendianness of the architecture or error control are to be worked into theimplementation of RPC. All the sender has to worry about is calling andreturning.RPC mechanisms are common in networked environments. Theabstraction is similar to the socket abstraction, except that data doesnot flow back and forth arbitrarily. Data is sent in a single messageand received when the remote procedure is done. RPC mechanisms areuseful in situations where short messages must be exchanged but controlis required.
RPC is analogous to the stream mechanism.IPC in Symbian OSIPC is central to the implementation of Symbian OS. Since it has a microkernel design, much of the operating system’s functionality is pushedinto servers running at the user level. These servers communicate witheach other, with the kernel and with user applications on a socket-based,client–server-oriented basis.User-level objects in Symbian OS use a socket-based system to communicate.
A user-level server is an active object (remember active objectsfrom Chapter 4?) that waits for connections with requests and servicesthem. Data is exchanged through the sockets via objects from the RMessage2 class. Remote procedure calls are not used in Symbian OS.MANAGING DEADLOCKS1336.8 Managing DeadlocksWhen processes wait for each other, either directly or in some circularmanner, we call the situation a deadlock.
Consider a simple situationof a bank transfer. Let’s say that two processes – say, two people at twoautomated teller machines – desire to transfer funds between the sametwo accounts. The processes that they go through are shown in Figure 6.2.In the simple scenario where Process A executes its first statement,followed by Process B executing its first statement, deadlock ensues whenProcess A executes its second statement and Process B executes its secondstatement. This is because Process A is waiting for Process B, which iswaiting for Process A.For a deadlock situation to occur, four conditions must be present:• at least one resource must be acquired for exclusive use by a process• that process must be waiting to acquire another resource in the system• a circular waiting set must exist, where each process is dependent onresources held by another process• pre-emption cannot be allowed to free resources.Deadlock situations require that the operating system detects andrecovers from deadlocks.
Deadlock detection is a matter of analyzingthe relationships between processes. The operating system should maintain a table of structure resource requests. When a process requestsaccess to a resource that is allocated to another process, an entry in thestructure should indicate the waiting relationship. The result is a graphProcess AProcess Block (account A)lock (account B)lock (account B)lock (account A)decrement $100 from account Adecrement $100 from account Bincrement account B by $100increment account A by $100unlock (account B)unlock (account A)unlock (account A)unlock (account B)Figure 6.2 Process definition for transferring money134PROCESS CONCURRENCY AND SYNCHRONIZATIONof relationships between processes.
This graph needs to be checkedperiodically for cycles. When a cycle exists, a deadlock situation hasoccurred.Recovering from a deadlock situation can be a difficult operation. Thereare two ways to break a deadlock: process termination and resource preemption. To break a deadlock by process termination, the operatingsystem needs to terminate one or more processes that are involved in thecycle detected in the resource allocation graph. Terminating all processesis a simple solution; finding and terminating only one crucial process canbe difficult.
The single-process approach is a decision based on manyfactors, including the priority of the process, the length of time the processhas been executing, how many other resources are used by the process,and how many resources are still needed by the process.To break a deadlock by resource pre-emption, the operating systemmust choose the resource and the process to pre-empt. Sometimes thischoice is simple: a single resource may be the logjam and it maybe obvious which process has that resource. However, there must becomputable ways to make this choice. In addition, once the deadlock isbroken, it may occur again and we must somehow ensure that the sameprocess accessing the critical resource is not always chosen again (thatwould cause a starvation situation).
Another, more gentle, approach is torollback a process to a safe state. The process under examination is notterminated but reset to a state where the critical resource can be allocatedto another process. Most of the time this actually means restarting theprocess, because determining a safe state usually is not possible.6.9 SummaryThis chapter has been devoted to issues surrounding the concurrency ofprocesses in an operating system. We first introduced what happens whenprocess interleave their statements and instructions. We then describedthe goal of serializability and ways that we could algorithmically synchronize processes to share resources properly.
We introduced semaphores asa way to make synchronization easier. We developed other abstractionsthat built on and expanded semaphores. We then worked through theDining Philosophers’ Problem and demonstrated semaphores in Linux.We then discussed concurrency in Symbian OS. We introduced interprocess communication via message passing, sockets, and remote procedurecalls. We finished the chapter by discussing ways to manage deadlocks.EXERCISES135Exercises1.We discussed busy waiting as a special case of waiting in anoperating system.
What other kinds of waiting can go on in anoperating system?2.How is it possible to execute only half of a statement before acontext switch is made?3.We stated that making processes be truly serial – executing oneafter the other – would have a bad effect on performance. Doesserializable access have the same performance hit? Explain youranswer.4.Prove that the following algorithm (the final solution to synchronizing two processes shown in Section 6.1) does indeed adhere tothe three criteria of mutual exclusion, no starvation and boundedwaiting.while (true){ready[myID] = true;turn = nextID;while (ready[nextID] && turn == nextID) ;// critical sectionready[myID] = false;// whatever else needs to be done}5.Show that if the manipulation of semaphores through wait() andsignal() were not atomic, that mutual exclusion may be violated.6.Should interrupts be disabled during the manipulation of semaphores? Explain.7.The following code shows the critical region from the discussionabout locks in Section 6.3.
Rewrite it using semaphores.region time_buffer when (timing_count > 0){136PROCESS CONCURRENCY AND SYNCHRONIZATIONtiming_data = time_buffer[time_out];time_out = (time_out + 1) % buffer_size;timing_count --;display(timing_data);}8.Implementation of monitors can restrict the way semaphores areobtained and released. Explain why a signal() call must be thelast call for a monitor implementation.9.Explain why a mutex is necessary in Symbian OS. Would asemaphore with a value of 1 also work?10.Explain why the two-tier implementations of mutexes and semaphores (in the nanokernel and the kernel) is necessary in SymbianOS.11.Are sockets based on the mail model or the phone model of IPC?Explain your answer.12.Symbian OS does not implement remote procedure calls.
Can RPCbehavior be implemented with sockets? Explain.13.Why does an operating system need multiple types of locks?7Memory ManagementIn the last several chapters, we have discussed how the CPU can beshared as a resource among processes. By proper scheduling and usingconcurrency, we can use the CPU more efficiently and increase theperformance of the operating system. There are other resources in acomputer system that also require sharing; after the CPU, a computer’smemory is one of the most crucial.
Proper sharing of memory also affectsan operating system’s efficiency and performance.In this chapter, we discuss memory management. We develop thebackground and concepts necessary for this discussion and discuss management techniques. Many of these management concepts apply todesktop computers and servers, but some do not work with handheldunits and smartphones. So we spend some time discussing systems thatdo not use all memory-management schemes. We use Symbian OS as anexample of smartphone memory management.Before we get started, the type of memory we are concerned withshould be made clear.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
