On Sun, 2005-04-10 at 04:09, Ingo Molnar wrote:
> Unless i'm missing something, this could be implemented by detaching
> lock->owner_prio from lock->owner - via e.g. negative values. Thus some
> minimal code would check whether we need the owner's priority in the PI
> logic, or the semaphore's "own
I looked at the PI-code to see what priority the task (old_owner below)
would end up with when it released a lock. From rt.c:
prio = mutex_getprio(old_owner);
if (new_owner && !plist_empty(&new_owner->pi_waiters)) {
w = plist_entry(&new_owner->pi_waiters, struct
rt_
On Thu, Apr 07, 2005 at 10:52:25AM -0700, Daniel Walker wrote:
>
> Source: Daniel Walker <[EMAIL PROTECTED]> MontaVista Software, Inc
> Description:
> This patch adds the priority list data structure from Inaky
> Perez-Gonzalez
> to the Preempt Real-Time mutex.
>
> the patch order is (sta
>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>
>> Quick fix: the usual. Enable deadlock detection and if it
>> returns deadlock, assume it is locked already and proceed (or
>> do a recursive mutex, or a trylock).
>
>You have to be joking me ? geez.
>...
This is way *more* common than you think
On Mon, Apr 11, 2005 at 04:28:25PM -0700, Perez-Gonzalez, Inaky wrote:
> >From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
...
> API than once upon a time was made multithreaded by just adding
> a bunch of pthread_mutex_[un]lock() at the API entry point...
> without realizing that some of the top le
>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote:
>> If you are exposing the kernel locks to userspace to implement
>> mutexes (eg POSIX mutexes), deadlock checking is a feature you want
>> to have to complain with POSIX. Accord
On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote:
> If you are exposing the kernel locks to userspace to implement
> mutexes (eg POSIX mutexes), deadlock checking is a feature you want
> to have to complain with POSIX. According to some off the record
> requirements I've been g
>From: Bill Huey (hui) [mailto:[EMAIL PROTECTED]
>
>On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote:
>>
>> * Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>>
>> > Let me re-phrase then: it is a must have only on PI, to make sure
you
>> > don't have a loop when doing it. Maybe is a co
On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote:
>
> * Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
> > Let me re-phrase then: it is a must have only on PI, to make sure you
> > don't have a loop when doing it. Maybe is a consequence of the
> > algorithm I chose. -However- it
On Sun, 2005-04-10 at 03:53, Ingo Molnar wrote:
> ok, i've added this patch to the -45-00 release. It's looking good on my
> testsystems so far, but it will need some more testing i guess.
Yes, I ran the PI test, and just let the system run .. So it could use
more extensive testing..
Daniel
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
>> Let me re-phrase then: it is a must have only on PI, to make sure you
>> don't have a loop when doing it. Maybe is a consequence of the
>> algorithm I chose. -However- it should be possible to di
* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
> Let me re-phrase then: it is a must have only on PI, to make sure you
> don't have a loop when doing it. Maybe is a consequence of the
> algorithm I chose. -However- it should be possible to disable it in
> cases where you are reasonably sur
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
>> >OTOH, deadlock detection is another issue. It's quite expensive and
i'm
>> >not sure we want to make it a runtime thing. But for fusyn's
deadlock
>> >detection and safe teardown on owner-exit is
* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
> >OTOH, deadlock detection is another issue. It's quite expensive and i'm
> >not sure we want to make it a runtime thing. But for fusyn's deadlock
> >detection and safe teardown on owner-exit is a must-have i suspect?
>
> Not really. Deadlock c
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>
>i'd not mind merging the extra bits to PREEMPT_RT to enable fusyn's, if
>they come in small, clean steps. E.g. Daniel's plist.h stuff was nice
>and clean.
I am finishing breaking it up in small bits so you can take a look
at it. Should be finished
* Sven-Thorsten Dietrich <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-04-08 at 08:28 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > This patch adds the priority list data structure from Inaky
> > > Perez-Gonzalez to the Preempt Real-Time mutex.
> >
> > this o
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> Description:
> This patch adds the priority list data structure from Inaky
> Perez-Gonzalez to the Preempt Real-Time mutex.
ok, i've added this patch to the -45-00 release. It's looking good on my
testsystems so far, but it will need some more
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>> Current tip of development has some issues with conditional variables
>> and broadcasts (requeue stuff) that I need to sink my teeth in. Joe
>> Korty is fixing up a lot of corner cases I wasn't catching, but
>> other than that is doing fine.
>
>Yo
On Fri, 2005-04-08 at 14:25, Perez-Gonzalez, Inaky wrote:
> I concur with Daniel. If we can decide how to deal with that (toss
> one out, keep one, merge them, whatever), we could reuse all the user
> space glue that is the hardest part to get right.
I have a preference to the Real-Time PI
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>On Thu, 2005-04-07 at 23:28, Ingo Molnar wrote:
>
>> this one looks really clean.
>>
>> it makes me wonder, what is the current status of fusyn's? Such a
light
>> datastructure would be much more mergeable upstream than the former
>> 100-queues appr
On Thu, 2005-04-07 at 23:28, Ingo Molnar wrote:
> this one looks really clean.
>
> it makes me wonder, what is the current status of fusyn's? Such a light
> datastructure would be much more mergeable upstream than the former
> 100-queues approach.
Inaky was telling me that 100 queues
On Fri, 2005-04-08 at 08:28 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > This patch adds the priority list data structure from Inaky
> > Perez-Gonzalez to the Preempt Real-Time mutex.
>
> this one looks really clean.
>
> it makes me wonder, what is the curren
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> This patch adds the priority list data structure from Inaky
> Perez-Gonzalez to the Preempt Real-Time mutex.
this one looks really clean.
it makes me wonder, what is the current status of fusyn's? Such a light
datastructure would be much more
Source: Daniel Walker <[EMAIL PROTECTED]> MontaVista Software, Inc
Description:
This patch adds the priority list data structure from Inaky
Perez-Gonzalez
to the Preempt Real-Time mutex.
the patch order is (starting with a 2.6.11 kernel tree),
patch-2.6.12-rc2
realtime-preempt-2.6.12-r
24 matches
Mail list logo
