<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-0A7AB5BF-B126-4A3C-AC0D-C5443C06A82E" xml:lang="en"><title>Thread

Priority and Delayed Cancellation</title><shortdesc>This document describes problems caused due to delayed cancellation

of threads.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>The basic problem is when Thread A has previously requested a Notification

of some status change and now requests that the Notification be cancelled. </p>

<p>Thread A starts Thread B to talk to the Server. Thread B sends the cancellation

request to the Server and sends a completion message back to Thread A to say

that the cancel request has been sent to the Server.</p>

<p>In the past Thread B would not have returned until the Server cancellation

had completed. But with SMP the cancellation request may be placed on a second

CPU and delayed for various reasons, while Threads A and B continue. It is

possible for a Notification event to occur at this point and a panic will

occur when the Notification arrives without a process to handle it.</p>

<p>The single core device had fewer problems with thread priority issues like

delayed cancellation, because the Server ran with higher priority and completed

the cancellation before returning control to Thread B. On a multiple core

system, different threads run in parallel and this may lead to errors.</p>

<p>You should be aware that deadlocks or panics can be caused due to delayed

cancellation of threads and write your code to avoid it.</p>

<section id="GUID-B5C37041-10A9-4D29-A4DC-A4B884FD23AB"><title>Example</title><p>One

possible solution is to send the cancel completion message from the <codeph>RunL()</codeph> function

call of the server.</p><fig id="GUID-6792304C-AE6D-450A-B4BE-60B48F981CF5">

<title>Error in cancellation sequence</title>

<image href="GUID-F492978A-1732-4BCD-8D3C-D2F657BAB504_d0e17290_href.png" placement="inline"/>

</fig></section>

<example><title>Client code</title><codeblock xml:space="preserve">// [...]

//Whilst running

  iNotifier.RequestNotification(iStatus);

// [...]

//Some part of the client is now waiting for 

  notifications on iStatus

// [...] at some point during exit

  iNotifier.CancelNotification();

  iNotifier.Close();  

// Notifier session can be taken down now.

</codeblock></example>

<example><title>Server code</title><codeblock xml:space="preserve">void CCommsdatNotifierSessionHandler::RegisterNotifyL(

	const RMessage2& aMessage)

    {

…

    iMessage = aMessage;

…

        iProperty.Subscribe(iStatus);

        SetActive();

 void CCommsdatNotifierSessionHandler::CancelNotify(

		const RMessage2& aMessage)

    {

    iProperty.Cancel();

    …

    aMessage.Complete(KErrCancel);

    }

void CCommsdatNotifierSessionHandler::RunL()

    {

…

    iMessage.Complete(…);

…

    }

</codeblock></example>

<example><title>Solution for server code</title><codeblock xml:space="preserve">void CCommsdatNotifierSessionHandler::RegisterNotifyL(

	const RMessage2& aMessage)

    {

…

    iMessage = aMessage;

…

        iProperty.Subscribe(iStatus);

        SetActive();

 Void CCommsdatNotifierSessionHandler::CancelNotify(const RMessage2 &aMessage)

{

iProperty.Cancel();

...

iCancelMessage = aMessage;

}

Void CCOmmsdatNotifierSessionHandler::RunL()

{

...

iMessage.Complete(...);

iCancelMessage.Complete(KErrNone);

...

}</codeblock></example>

</conbody><related-links>

<link href="GUID-E55F9286-F586-4665-93D8-86F1E7BE2C7C.dita"><linktext>SMP Developer

Tips</linktext></link>

</related-links></concept>