Smartphone Operating System (779883), страница 28
Текст из файла (страница 28)
First, mutexes are not obtained until the last possiblemoment, to give other processes as much time to get in the waiting128PROCESS CONCURRENCY AND SYNCHRONIZATIONqueue as possible. Secondly, Symbian OS uses priority inheritance. In thecase of the low-priority process holding a mutex, the operating systemraises the priority of the low-priority process to that of the highest processwaiting for the mutex.
This is to ensure that no other process, whosepriority is higher than the low-priority process, would be running before itand postpone its releasing of the mutex sooner. Finally, there are specialqueues for processes that are suspended while waiting for a mutex. Theoperating system does not give mutexes to suspended processes becausethe mutex might be acquired for some undetermined time.6.7 Interprocess CommunicationOne can certainly consider the use of synchronization primitives as a formof communication between processes. Processes that are synchronizedover semaphores do indeed communicate the need for mutual exclusion.Often, however, more information needs to be exchanged betweenprocesses and therefore a more complicated set of semantics is required.Interprocess communication (IPC) builds on the ideas developed forprocess synchronization but adds concepts of data transfer and morecomplex exchange semantics.ConceptsCooperating processes can share information between them in severalways.
One of the more obvious ways is by expanding the ideas ofsemaphores into full-blown shared-memory environments. If a kernelcan implement shared objects such as semaphores, then it surely canexpand to accommodate other kinds of shared-memory models. The ideaof a shared-memory environment requires the kernel to provide memoryresources, implemented as variables or buffers inside applications, toprocesses upon request. Multiple processes can request the same memoryarea and any changes to that memory affects all processes.Using shared memory, however, is a lot like using global variablesin a program.
Shared memory must be used carefully; effects are immediate and parallel usage must be synchronized. There are other, moreabstract, ways to communicate between processes. These other wayshave synchronization built-in and do not require sharing memory.Interprocess communication is best provided through the use of message passing. As with all ways of exchanging information, messageINTERPROCESS COMMUNICATION129passing requires a sender and a receiver. The way that they work togetherto exchange a message results in two models for passing informationbetween concurrent units: the mail model and the phone model.
Thedifference between these two models lies in whether or not the receivingunit needs to attend to the message before the sending unit may proceed.The mail modelInformation is sent by process P1 to process P2 and placed in a mailbox.Process P1 may then proceed with its execution and process P2 maycome and retrieve the message at a later time. If more than one messageis sent to the same mailbox, the messages are usually queued up withinthe mailbox so that process P2 may successively retrieve messages untilthe mailbox is empty.There are several ways that the mailbox might be identified, providingdifferent versions of the mail model. These are distinguished by the way inwhich communication takes place. The many-to-one version is analogousto the way a typical post office mailbox operates, with messages arrivingfrom any of a number of processes, but only destined for one specificprocess.
Therefore, the sender specifies the receiver of the message, butthe receiver retrieves messages without needing to specify the sender.The one-to-one version accepts messages from one sender. Herethe sender must not only specify the receiver, but when the receiverretrieves the message, it must specify the identity of the sender as well.
Agiven mailbox is then identified with both the sending and the receivingprocesses. This is similar to a mailbox used to pass information from aboss to a secretary where all messages come from the same sender andall go to the same receiver.The many-to-many version accepts messages from many processes andthese messages may be retrieved by many processes. A sending processtherefore places the message in the mailbox without specifying who thereceiver is to be. The next process to retrieve from that mailbox is thereceiving process. This is similar to a mailbox in an office with manybosses and many secretaries where a boss puts a job to be done in amailbox and the next available secretary retrieves the message from thebox and does the job specified.The phone modelUnder the mail model, the sender simply sends the message and doesnot wait for message receipt.
The second model for passing information,130PROCESS CONCURRENCY AND SYNCHRONIZATIONthe phone model, requires that the sending unit wait for the receivingunit to accept the message before proceeding. This is analogous toplacing a phone call where the caller must wait for the person calledto respond before the message can be sent. The phone model is alsoknown as the rendezvous model, where two people meet together at aprearranged location to pass information.
By its nature, the phone modelalso synchronizes the two processes since they must wait to make asimultaneous contact for the message to be sent.There are two forms of the phone model, each with different views ofwaiting. In the first form, the sender waits only for notification from thereceiver that the message has been received and, upon this notification,both processes continue with their execution. In the second form, thesender waits for both message receipt and message processing. Thissecond version of the phone model is similar to a procedure call;the caller calls the procedure, sending parameters, and waits until thisprocedure returns, possibly with modified parameters.
The analogy is sostrong, in fact, that this second form of the phone model is typicallyreferred to as a remote procedure call.As with the mail model, the phone model might be one-to-many,one-to-one, or many-to-many.SocketsSockets were invented by the designers of Berkeley Unix and were firstused as a way to access network protocols. In the Berkeley terminology,a socket is an ‘endpoint for communication’. By itself, as an endpoint,a socket is not very useful. But when connected to another socket onanother computer, the pair become a communication channel that usesa protocol to transfer data. You can think of sockets as two ends of aconversation and the protocol as the translator.Sockets require both a client and a server. The client connects to itsend of the socket and makes a request to the server for connection. Theserver either replies with no connection or connects to its end and repliespositively.
Then data is exchanged across the socket.The beauty of the socket model is in its abstractness and its translationabilities. The abstractness of the model can be seen in how it is used: eachside simply writes data to and reads data from a socket as if it was anyother local I/O device. Each side really does not know (or care) how theother side reads or processes the data. In fact, the socket may implementINTERPROCESS COMMUNICATION131translation of data, again without each side knowing (or caring). Thetranslation is implemented by the operating system and occurs as the datais transferred between the endpoints.
These translations may be as simpleas little-endian to big-endian or as complicated as using the Bluetoothprotocol.Sockets have certain properties, chosen based on how they are used.A socket is either connected or connectionless. A connected socketmaintains a virtual connection between the two endpoints. This meansthat address information for the remote endpoint needs to be given onlyonce, and that each access to the connection can be done withoutspecifying this information again. A connectionless socket forces theapplication to specify the remote endpoint information each time it isused and has no virtual connection.
A connected socket is easier to useand is more reliable yet requires higher overhead in its implementation.Connected sockets use mechanisms to ensure that data arrives at theremote endpoint in the exact order they were sent and that they arriveerror-free or do not arrive at all. Connectionless sockets make no suchguarantees about data arrival or reliability.Connected sockets are implemented with streams.
A stream is alogical connection between two endpoints that implements the followingproperties:• reliability : with a stream, data is delivered accurately (as they weresent) without error or it is not delivered at all; if there is no datadelivery, this is detected and the socket owner is notified• error control : errors are detected automatically and the remote endpoint is usually asked to retransmit the data packet that had the error;maintaining error control usually involves using checksums on datapackets and forcing remote endpoints to acknowledge when theyreceive packets• ordered delivery : data that flows between two endpoints can bebroken up and sent as fragments; a stream makes sure those fragmentsarrive at their destination in the order in which they were sent andthat the larger data packets are reassembled correctly.The reliability of connected sockets comes at a price.
There are moreprotocol layers involved and hence more protocol overhead. There ismore communication between endpoints and hence more data traffic.132PROCESS CONCURRENCY AND SYNCHRONIZATIONRemote Procedure CallsRemote procedure calls (RPCs) describe a very commonly used set ofIPC semantics. Using the phone model of IPC, if we force the senderto identify the receiver, and block the sender until the receiver is doneprocessing the message that was sent, we then have semantics that mirrorthose of procedures in a programming language. The act of sending ismuch like the act of calling a procedure, except that the procedure is ona remote process.To complete the analogy, we need a few more concepts. When aprocedure call is made, data is transferred to the called procedure inthe form of parameters and passed back to the caller in the form of areturn value. We can use these ideas for RPC: the RPC call transfers datafrom sender to receiver and the receiver can send data back througha return value abstraction.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
