From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [bug] broken PI-chain
Date: Fri, 25 Aug 2006 20:33:54 +0200 [thread overview]
Message-ID: <1156530834.4338.42.camel@domain.hid> (raw)
In-Reply-To: <44EF2BA6.9040601@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
On Fri, 2006-08-25 at 18:56 +0200, Jan Kiszka wrote:
> Hi,
>
> the following (academic?) scenario is not handled as expected by the
> nucleus:
>
> Prio ^
> | -- T2
> | /
> | T0 <----- T1 <- M1
> | (M0) M0 (M1)
> +------------------------
>
> That means: Task T0 at, e.g., prio 1 holds mutex M0. T1, also at prio 1,
> happens to interrupt T0 (round-robin?). T1 already holds M1 and now
> tries to acquire M0. As both are at the same prio level, no boosting
> takes place, all fine. Then T2 comes in play. It's at prio 2 and tries
> to gain access to M1. T1 gets therefore boosted to prio 2 as well, but
> T0 will stay at prio 1 under Xenomai.
>
Ok, confirmed. The way the PI chain is handled is very academically
broken.
> I hacked this scenario in the attached demo. Set MAX to 2 to let it
> work, leave it 3 and it breaks.
Ouch. It does indeed...
>
> The problem looks on first sight like this test [1]: the claiming
> relation is only establish if there is a priority delta on entry, but
> that breaks when the claiming thread's prio changes later. Can we simply
> remove this test?
It seems that there is even more than this, and I'm wondering now if
something fishy is not happening with the CLAIMED bit handling too, when
an attempt is made to clear the priority boost.
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/synch.c?v=SVN-trunk#L265
I've slightly adapted your test code so that my friend the simulator
helps us, and a segfault is raised upon exit of task_func(), which goes
south, likely trying to flush the pend queue of some synch object it
should not still be waiting for.
FWIW, I've attached the code and the Makefile adapted to the simulator.
--
Philippe.
[-- Attachment #2: Makefile --]
[-- Type: text/x-makefile, Size: 502 bytes --]
# Allow overriding xeno-config on make command line
XENO_CONFIG=xeno-config
prefix := $(shell $(XENO_CONFIG) --prefix)
ifeq ($(prefix),)
$(error Please add <xenomai-install-path>/bin to your PATH variable)
endif
GCIC := $(prefix)/bin/gcic
SIM_CFLAGS := -g
SIM_LDFLAGS := -lnative_sim
SIM_TARGETS := pip-chain
sim: $(SIM_TARGETS)
all: sim
$(SIM_TARGETS): $(SIM_TARGETS:%=%.o)
$(GCIC) -o $@ $^ $(SIM_LDFLAGS)
%.o: %.c
$(GCIC) -o $@ -c $< $(SIM_CFLAGS)
clean:
$(RM) -f *.o *_s.o $(SIM_TARGETS)
[-- Attachment #3: pip-chain.c --]
[-- Type: text/x-csrc, Size: 918 bytes --]
#include <stdio.h>
#include <sys/mman.h>
#include <native/task.h>
#include <native/mutex.h>
#define MAX 3
RT_MUTEX mutex[3];
RT_TASK task[3], main_tcb;
void task_func(void *arg)
{
int index = (int)arg;
rt_mutex_lock(&mutex[index], TM_INFINITE);
rt_mutex_lock(&mutex[index-1], TM_INFINITE);
rt_mutex_unlock(&mutex[index]);
}
void task_init(void *arg)
{
RT_TASK_INFO info;
int i;
for (i = 0; i < 3; i++)
rt_mutex_create(&mutex[i], NULL);
rt_mutex_lock(&mutex[0], TM_INFINITE);
for (i = 1; i < MAX; i++)
rt_task_spawn(&task[i], NULL, 0, (i == MAX-1) ? 2 : 1, 0, task_func, (void *)i);
rt_task_inquire(NULL, &info);
printf("MAX=%d, prio=%d\n", MAX, info.cprio);
rt_mutex_unlock(&mutex[0]);
for (i = 0; i < 3; i++)
rt_mutex_delete(&mutex[i]);
}
int root_thread_init(void)
{
return rt_task_spawn(&main_tcb, "task_init", 0, 1, T_JOINABLE, task_init, 0);
}
void root_thread_exit(void)
{
}
next prev parent reply other threads:[~2006-08-25 18:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-25 16:56 [Xenomai-core] [bug] broken PI-chain Jan Kiszka
2006-08-25 18:33 ` Philippe Gerum [this message]
2006-08-25 20:11 ` Philippe Gerum
2006-08-26 0:03 ` Philippe Gerum
2006-08-26 8:07 ` Jan Kiszka
2006-08-26 8:44 ` Philippe Gerum
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=1156530834.4338.42.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=jan.kiszka@domain.hid \
--cc=xenomai@xenomai.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.