|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 849-850 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 849
818
CASE STUDY 1: UNIX, LINUX, AND ANDROID
CHAP. 10
the sender.
It determines which process is responsible for the target of the transac-
tion and wakes up a thread in the process to receive it. Once the receiving process
is executing, it determines the appropriate target of the transaction and delivers it.
Process 1
Process 2
Transaction
To: Object1
From: Process 1
(Data)
Object1
Thread pool
Transaction
To: Object1
(Data)
Thread pool
Kernel
Transaction
To: Object1
From: Process 1
(Data)
T1
T1
T2
T2
Ta
Figure 10-43.
Basic
Binder
IPC transaction.
(For the discussion here, we are simplifying the the way transaction data
moves through the system as two copies, one to the kernel and one to the receiving
process’s address space.
The actual implementation does this in one copy. For
each process that can receive transactions, the kernel creates a shared memory area
with it.
When it is handling a transaction, it first determines the process that will
be receiving that transaction and copies the data directly into that shared address
space.)
Note that each process in Fig.10-43 has a ‘‘thread pool.’’ This is one or more
threads created by user space to handle incoming transactions.
The kernel will dis-
patch each incoming transaction to a thread currently waiting for work in that proc-
ess’s thread pool.
Calls into the kernel from a sending process however do not
need to come from the thread pool—any thread in the process is free to initiate a
transaction, such as
Ta
in Fig. 10-43.
We have already seen that transactions given to the kernel identify a target
ob-
ject
; however, the kernel must determine the receiving
process
.
To accomplish
this, the kernel keeps track of the available objects in each process and maps them
to other processes, as shown in Fig. 10-44. The objects we are looking at here are
simply locations in the address space of that process.
The kernel only keeps track
of these object addresses, with no meaning attached to them; they may be the loca-
tion of a C data structure, C++ object, or anything else located in that process’s ad-
dress space.
References to objects in remote processes are identified by an integer
handle
,
which is much like a Linux file descriptor.
For example, consider
Object2a
in
Page 850
SEC. 10.8
ANDROID
819
Process 2
—this is known by the kernel to be associated with
Process 2
, and further
the kernel has assigned
Handle 2
for it in
Process 1
.
Process 1
can thus submit a
transaction to the kernel targeted to its
Handle 2
, and from that the kernel can de-
termine this is being sent to
Process 2
and specifically
Object2a
in that process.
Process 1
Process 1
Process 2
Object1a
Object1a
Object2a
Object2a
Object2b
Object2b
Object1b
Object1b
Handle 2
Handle 2
Handle 1
Handle 1
Handle 2
Handle 2
Handle 3
Handle 3
Process 2
Kernel
Figure 10-44.
Binder
cross-process object mapping.
Also like file descriptors, the value of a handle in one process does not mean
the same thing as that value in another process.
For example, in Fig. 10-44, we can
see that in
Process 1
, a handle value of 2 identifies
Object2a
; however, in
Process
2
, that same handle value of 2 identifies
Object1a
.
Further, it is impossible for one
process to access an object in another process if the kernel has not assigned a hand-
le to it for
that process
.
Again in Fig. 10-44, we can see that
Process 2
’s
Object2b
is known by the kernel, but no handle has been assigned to it for
Process 1
. There
is thus no path for
Process 1
to access that object, even if the kernel has assigned
handles to it for other processes.
How do these handle-to-object associations get set up in the first place?
Unlike Linux file descriptors, user processes do not directly ask for handles.
In-
stead, the kernel assigns handles to processes as needed.
This process is illustrated
in Fig. 10-45. Here we are looking at how the reference to
Object1b
from
Process
2
to
Process 1
in the previous figure may have come about.
The key to this is how
a transaction flows through the system, from left to right at the bottom of the fig-
ure.
The key steps shown in Fig. 10-45 are:
1.
Process 1
creates the initial transaction structure, which contains the
local address
Object1b
.
2.
Process 1
submits the transaction to the kernel.
3.
The kernel looks at the data in the transaction, finds the address
Ob-
ject1b
, and creates a new entry for it since it did not previously know
about this address.
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
