Concepts with Symbian OS (779878), страница 27
Текст из файла (страница 27)
The semaphores make the entiresolution work.6.6 Concurrency in Symbian OSAs we have stated in previous chapters, Symbian OS supports concurrencybetween processes. We have also seen how the Symbian OS kernel issupported by the Symbian OS nanokernel. In addition, the Symbian OSarchitecture is essentially that of a microkernel. Therefore, we can expectsynchronization primitives to be implemented in the kernel.For Symbian OS, however, this is not as simple as it may seem.Because of nanokernel support, there are multiple kinds of semaphores,implemented at both levels in the kernel.The most primitive objects are in the nanokernel.
The nanokernel’ssupport for synchronization takes the form of two types of objects:mutexes and semaphores. A mutex is essentially a binary semaphore:it has only two states and is designed to implement mutual exclusion between two processes. A semaphore is a more general form ofa mutex; it can hold values greater than 1, allowing mutual exclusionCONCURRENCY IN SYMBIAN OS127between multiple processes. Both blocking and nonblocking mutexes andsemaphores are supported. The recommended way of using nanothreadsynchronization is through the NKern class, which allows blocking calls.The FMWait() and FMSignal() methods implement blocking synchronization for mutexes; FSWait() and FSSignal() implement suchfunctionality for semaphores.
Nonblocking use of these synchronizationobjects is provided through other classes; nanokernel mutexes are implemented in the NFastMutex class and semaphores are implemented inthe NFastSemaphore class. When access is nonblocking, only oneprocess may acquire access through a mutex and all others requestingaccess (say, through a wait() call) are rejected, but not forced to wait.Waiting is expensive to implement and the nanokernel is designedto be as fast as possible. However, using nonblocking synchronizationmeans that the kernel needs to be locked as the synchronization object ischecked.
It also means that if a process wants to implement waiting withnanokernel primitives, it must implement its own wait cycle. This meansthat nonblocking calls are expensive as well. The safest route is to let thekernel handle waiting.Kernel objects in Symbian OS are built on top of nanokernel objects.Thus, the kernel has analogous synchronization primitives: mutexes andsemaphores. Kernel mutexes are binary semaphores and implement someof the semaphore properties that nanokernel mutexes do not. For example,the versions of wait() and signal() that are implemented for kernelmutexes allow for blocking and queuing: multiple processes may callwait() on a mutex and they block while they wait their turn. It is possibleto hold several kernel mutexes simultaneously.
Counting semaphores arealso implemented by the Symbian OS kernel. As with mutexes, thesesemaphores are blocking and processes may hold multiple semaphoresat once. Mutexes in the kernel are implemented by the RMutex class andsemaphores by the RSemaphore class.There is an interesting issue that applies to synchronization primitivesin Symbian OS: process priority. Process priority and mutexes providean interesting dilemma.
Symbian OS has the property that if processeswith different priorities are waiting for a mutex, then the process withthe highest priority should be next to acquire the mutex when it isreleased. However, if a lower-priority process holds the mutex, then itcan delay a higher-priority process. This is quite undesirable and thedesigners of Symbian OS have installed some mechanisms to keep itfrom happening. 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.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
