From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <44625A66.307@domain.hid> Date: Wed, 10 May 2006 23:25:58 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-core] Pending ownership and resource stealing References: <44619D0B.1080402@domain.hid> <4461BB5A.3010403@domain.hid> <44621B00.7090703@domain.hid> <17506.9231.555209.471522@domain.hid> <44623377.2090801@domain.hid> <17506.18027.836408.819871@domain.hid> In-Reply-To: <17506.18027.836408.819871@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > prio(task1) > prio(task2) > > > > 1. task1 grabs a resource > > 2. task1 sleeps for some time > > 3. task2 blocks requesting the resource > > 4. task1 wakes up from the sleep and releases the resource to task2 > > 5. task1 wants the resource back immediately and calls > > xnsynch_sleep_on() since the ownership has been transferred to task2 > > since step 4. > > 6a. old way: task1 would block and task2 would run anyway, with a PIP > > boost, blocking task1 until the resource is released > > 6b. new way: task1 steals the resource previously granted to task2 > > directly from xnsynch_sleep_on(), but doing so, nobody downstream has > > had a chance to update any skin-specific data, such as an additional > > "owner" field. > > Posix skin mutexes work the new way without calling xnsynch_sleep_on, so > probably need fixing. > I don't see any additional information maintained by the skin, aside of the sem->count field, so that should be ok as it is. Is there anything else recorded for tracking the current ownership of a sem-mutex object? -- Philippe.