Implementation of a new Resource Sharing Protocol

[Sebastian Huber]

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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.