public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Cc: Bill Huey <bhuey@lnxw.com>,
	dwalker@mvista.com, mingo@elte.hu, linux-kernel@vger.kernel.org,
	Esben Nielsen <simlo@phys.au.dk>
Subject: Re: FUSYN and RT
Date: Fri, 15 Apr 2005 21:14:22 -0400	[thread overview]
Message-ID: <1113614062.4294.102.camel@localhost.localdomain> (raw)
In-Reply-To: <16992.20513.551920.826472@sodium.jf.intel.com>

On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> >>>>> Bill Huey (hui) <bhuey@lnxw.com> writes:
> 
> > Ok, I've been thinking about these issues and I believe there are a
> > number of misunderstandings here. The user and kernel space mutexes
> > need to be completely different implementations. I'll have more on
> > this later.
> 
> > First of all, priority transitivity should be discontinuous at the
> > user/kernel space boundary, but be propagated by the scheduler, via
> > an API or hook, upon a general priority boost to the thread in
> > question.
> 
> This is not necessarily true. My temperature-regulating thread should
> be able to promote a task so it works around priority invertion, no
> matter if they are sharing a kernel or user space lock. 
> 
> By following your method, the pi engine becomes unnecesarily complex;
> you have actually two engines following two different propagation
> chains (one kernel, one user). If your mutexes/locks/whatever are the
> same with a different cover, then you can simplify the whole
> implementation by leaps.
> 

I have to agree with Inaky too.  Fundamentally, PI is the same for the
system regardless of if the locks are user or kernel. I still don't see
the difference here.  But for other reasons, I feel that the user lock
should be a different structure from the kernel lock. That's why I
mentioned that it would be a good idea if Ingo modulized the PI portion.
So that part would be the same for both. If he doesn't have the time to
do it, I'll do it :-)  (Ingo, all you need to do is ask.)

[...]

> > There will be problems trying to implement a Posix read/write lock
> 
> As long as the concept of rwlock allows for it to have multiple owners
> (read locks need to have them), the procedure is mostly the
> same. However, this not being POSIX, nobody (yet) has asked for it.
> 

I don't think rwlocks work well with PI.  You can implement it, but it's
like implementing multiple inheritance for Object Oriented languages.
Java didn't implement it because they say keeping it out makes the code
cleaner (probably true), but the real reason I bet, was that
implementing it makes everything much more complex.  The same goes with
rwlocks with multiple readers and PI. Without it makes for a cleaner
solution (for users as well as developers), and with it, it just makes
everything more complex.

-- Steve



  reply	other threads:[~2005-04-16  1:15 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-12 20:35 FUSYN and RT Perez-Gonzalez, Inaky
2005-04-12 23:11 ` Esben Nielsen
2005-04-13  0:27   ` Daniel Walker
2005-04-13 15:46     ` Steven Rostedt
2005-04-13 17:33       ` Daniel Walker
2005-04-13 18:38         ` Steven Rostedt
2005-04-15 22:51       ` Bill Huey
2005-04-15 23:37         ` Inaky Perez-Gonzalez
2005-04-16  1:14           ` Steven Rostedt [this message]
2005-04-16  1:20             ` Inaky Perez-Gonzalez
2005-04-16  1:38               ` Steven Rostedt
2005-04-16  1:53                 ` Inaky Perez-Gonzalez
2005-04-16  2:31                   ` Steven Rostedt
2005-04-16  3:00                     ` Sven Dietrich
2005-04-16  3:31                       ` Steven Rostedt
2005-04-16 13:05                       ` john cooper
2005-04-16 14:23                         ` Steven Rostedt
2005-04-16 14:51                           ` john cooper
2005-04-16  4:05                     ` Inaky Perez-Gonzalez
2005-04-18  5:30           ` Bill Huey
2005-04-18  7:37             ` Sven-Thorsten Dietrich
2005-04-18 11:33               ` Steven Rostedt
  -- strict thread matches above, loose matches on Subject: below --
2005-04-12 23:36 Perez-Gonzalez, Inaky
2005-04-12 23:09 Perez-Gonzalez, Inaky
2005-04-12 22:26 Perez-Gonzalez, Inaky
2005-04-12 22:33 ` Daniel Walker
2005-04-12 21:28 Perez-Gonzalez, Inaky
2005-04-12 19:35 Perez-Gonzalez, Inaky
2005-04-12 18:15 Daniel Walker
2005-04-12 20:29 ` Esben Nielsen
2005-04-12 22:15   ` Daniel Walker
2005-04-12 20:33 ` Joe Korty
2005-04-12 21:25   ` Daniel Walker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1113614062.4294.102.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=bhuey@lnxw.com \
    --cc=dwalker@mvista.com \
    --cc=inaky@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=simlo@phys.au.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox