Implementation of a new Resource Sharing Protocol

Malte Münch mamu at stablerock.de
Tue Nov 13 08:37:41 UTC 2018


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.

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.

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.
> 



More information about the devel mailing list