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. >>>>> > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
