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