On 13/11/2018 09:58, Malte Münch wrote:
ok, so if i get this right _Thread_Dispatch_disable() and disabling of
interrupts both ensure that the current thread is not preempted and can
continue its spinning as it is waiting for its resource. As is seems to
me _Thread_Dispatch_disable is the better choice because all other
interrupts are processed, except they would dispatch a new thread and
therefore preempt the important thread.
Yes, spinning on something with interrupts disabled should be only done
if it is unavoidable, e.g. to acquire an SMP lock. Spinning on something
with thread dispatching disable should be also done with care.
In the MrsP implementation the spinning is done with thread dispatching
and interrupts enabled.
Your idea, with the debugger is good, but i think i will need some time
to figure out how to use it. I am currently using realview_pbx_a9_qemu
as my board.
The realview_pbx_a9_qemu is a good target to debug sequential and
non-timing sensitive problems.
Thanks so far.
Malte
On 13.11.18 09:42, Sebastian Huber wrote:
On 13/11/2018 09:37, Malte Münch wrote:
Good morning Sebastian,
thanks for your quick answer. Thanks for your hint on where to look for
the locking. I think i will need some time to understand what each macro
is doing.
My plan with the rtems_task_mode() call was to start there and trace
down to the according kernel call.
Please do not look at the rtems_task_mode() function. It uses a broken
mechanism:
https://devel.rtems.org/ticket/2365
In the operating system implementation disable interrupts to prevent a
thread dispatch or use _Thread_Dispatch_disable().
I will try this approach again with the MrsP implementation: what i need
is a FIFO-queue with spinlock-waiting which is, if i am not wrong, the
mechanism of MrsP with the exception that no priority ceiling per
processor is involved and that no helping mechanism is used.
I would use a debugger and follow the mutex obtain/release sequence in a
test case to figure out what is going on.
Best regards.
Malte
On 12.11.18 11:43, Sebastian Huber wrote:
Hello Malte,
On 12/11/2018 11:28, Malte Münch wrote:
Hi,
i am implementing a new resource sharing protocol for RTEMS as part of
my bachelor thesis. The thesis is about resource sharing protocols in
realtime environments on multicore systems. Right now i have to use a
spinlock for a protocol and found a helpful implementation/function in
cpukit/include/rtems/score/smplockmcs.h. My protocol requires the
calling task to be non-preemptable and the comment for the
acquire-function requires me to disable the interrupts.
the lock API for the operating system implementation is defined in
<rtems/score/isrlock.h>. Please do not use <rtems/score/smplock*.h>
directly.
The comment in cpukit/rtems/src/taskmode.c says that it is not possible
to change either interrupt levels or the preemptability of a task in a
SMP configuration. Do you have a pointer for me on how to overcome this
issue?
You look at the wrong layer. This rtems_task_mode() is a part of the
user API. It should not be used for the operating system implementation
which deals with locking protocols.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
