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_d0e234349_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_d0e234360_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>