Implementation of a new Resource Sharing Protocol

[Malte Münch]

Hello,

i am fiddling around with the mrsp-implementation for a while now. But
until now i am not able to divide the codeparts and understand what each
thing is doing. I am particularly interested in the part where the
helping mechanism is enabled. I want to replace it in a way that the
task is idling instead.

Can you give me a hint on where to look?

Thanks in advance

Malte

On 13.11.18 10:11, Sebastian Huber wrote:
> 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.
>>>>>
>