Philippe Gerum wrote:
On Fri, 2007-07-20 at 16:20 +0200, Jan Kiszka wrote:
OK, let's go through this another time, this time under the motto get
the locking right. As a start (and a help for myself), here comes an
overview of the scheme the final version may expose - as long as there
are
On Fri, 2007-07-20 at 16:20 +0200, Jan Kiszka wrote:
OK, let's go through this another time, this time under the motto get
the locking right. As a start (and a help for myself), here comes an
overview of the scheme the final version may expose - as long as there
are separate locks:
On Thu, 2007-07-19 at 19:57 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
Ok, the rpilock is local, the nesting level is bearable, let's focus on
putting this thingy straight.
Sorry, I missed this one, which in fact explains that you were referring
to Xenomai PI and not PREEMPT_RT PI
Philippe Gerum wrote:
...
Read my mail, without listening to your own grumble at the same time,
you should see that this is not a matter of being right or wrong, it is
a matter of who needs what, and how one will use Xenomai. Your grumble
does not prove anything unfortunately, otherwise
On Fri, 2007-07-20 at 16:20 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
...
Read my mail, without listening to your own grumble at the same time,
you should see that this is not a matter of being right or wrong, it is
a matter of who needs what, and how one will use Xenomai. Your
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be save?
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be save?
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
Philippe Gerum wrote:
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into
Philippe Gerum wrote:
Ok, the rpilock is local, the nesting level is bearable, let's focus on
putting this thingy straight.
Well, redesigning things may not necessarily improve the situation, but
reducing the amount of special RPI code might be worth a thought:
What is so special about RPI
On Thu, 2007-07-19 at 19:18 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue
Philippe Gerum wrote:
On Thu, 2007-07-19 at 19:18 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock,
13 matches
Mail list logo
