|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-D62A0234-348C-5553-B8C0-7B483AF9D50C" xml:lang="en"><title>Thread-relative |
|
13 and Process-relative handles</title><shortdesc>This document describes the difference between thread-relative |
|
14 and process-relative handles.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
15 <p>This is the issue of handle ownership.</p> |
|
16 <p>Threads and processes each maintain a list of objects to which they refer. |
|
17 This list is an object index and is the way in which handle-numbers representing |
|
18 these objects are generated.</p> |
|
19 <p>When user code causes a Kernel object (e.g. a mutex) to be created, ownership |
|
20 of the handle which is opened on that object may be vested either in the thread |
|
21 or the process. If ownership is vested in the thread, the handle associated |
|
22 with that object is said to be <i>thread-relative</i>, conversely, if ownership |
|
23 is vested in the process, the handle associated with that object is said to |
|
24 be<i>process-relative</i>.</p> |
|
25 <p>The following diagram shows the case where code belonging to thread A creates |
|
26 a mutex and vests ownership of the handle in the thread. </p> |
|
27 <fig id="GUID-5A22F71B-C146-53A9-B8A4-51D79D4EF668"> |
|
28 <title>Thread-relative handle</title> |
|
29 <image href="GUID-7B589949-2784-5B77-959E-99F8733A8853_d0e205732_href.png" placement="inline"/> |
|
30 </fig> |
|
31 <p>Compare with the following case where ownership of the mutex handle is |
|
32 vested in the process.</p> |
|
33 <fig id="GUID-6C60BB64-AE7B-5B46-983B-D6D65D8AB41C"> |
|
34 <title>Process-relative handle</title> |
|
35 <image href="GUID-47511301-DFF9-52B0-9602-DD9D293D3044_d0e205743_href.png" placement="inline"/> |
|
36 </fig> |
|
37 <p>In both cases, the mutex object is added to the appropriate Kernel container |
|
38 which can be considered as the owner of the object.</p> |
|
39 <p>The significance of a process-relative handle is that any thread in the |
|
40 process can use that handle to access the Kernel side object that the handle |
|
41 represents. In contrast, a thread-relative handle can only be used by the |
|
42 thread creating it; other threads in that process can only access the Kernel |
|
43 side object by <xref href="GUID-A4799558-AF8C-5E97-9B03-7D1C04FEC243.dita">duplicating</xref> that |
|
44 handle.</p> |
|
45 <p>For a thread-relative handle, the associated Kernel side object is closed |
|
46 if the thread dies. For a process-relative handle, the Kernel side object |
|
47 is closed if the process dies. Such an object is not closed if any thread |
|
48 belonging to that process dies; the object remains in existence for the lifetime |
|
49 of the process, or until all references to it have been explicitly closed.</p> |
|
50 <p>See also:</p> |
|
51 <ul> |
|
52 <li id="GUID-7355DCEE-85E8-58C6-9102-CBCE93251098"><p><xref href="GUID-A95CDFDE-285F-5DE2-AADE-29B2B9663757.dita">The |
|
53 object index</xref> </p> </li> |
|
54 </ul> |
|
55 </conbody></concept> |