Implementation of a new Resource Sharing Protocol

[Sebastian Huber]

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

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