Thank you for your answer. I learned ack today and it is coming pretty handy along with cscope.
On Thu, Jul 30, 2020 at 9:32 PM Gedare Bloom <ged...@rtems.org> wrote: > On Thu, Jul 30, 2020 at 7:30 AM Richi Dubey <richidu...@gmail.com> wrote: > > > > I request someone to help me with my earlier question: > https://lists.rtems.org/pipermail/devel/2020-July/060615.html since I may > reuse this logic of variable-sized arrays. > > > > I guess I'll answer here.. > > rtems$ ack Scheduler_EDF_SMP_Context > cpukit/score/src/scheduleredfsmp.c > 24:static inline Scheduler_EDF_SMP_Context * > 27: return (Scheduler_EDF_SMP_Context *) _Scheduler_Get_context( > scheduler ); > 30:static inline Scheduler_EDF_SMP_Context * > 33: return (Scheduler_EDF_SMP_Context *) context; > 63: Scheduler_EDF_SMP_Context *self = > 100: Scheduler_EDF_SMP_Context *self = _Scheduler_EDF_SMP_Get_self( > context ); > 121: Scheduler_EDF_SMP_Context *self, > 143: Scheduler_EDF_SMP_Context *self; > 192: Scheduler_EDF_SMP_Context *self, > 201: const Scheduler_EDF_SMP_Context *self, > 220: Scheduler_EDF_SMP_Context *self; > 241: Scheduler_EDF_SMP_Context *self; > 284: Scheduler_EDF_SMP_Context *self; > 307: Scheduler_EDF_SMP_Context *self; > 370: Scheduler_EDF_SMP_Context *self; > 586: Scheduler_EDF_SMP_Context *self; > > cpukit/include/rtems/score/scheduleredfsmp.h > 106:} Scheduler_EDF_SMP_Context; > > cpukit/include/rtems/scheduler.h > 133: Scheduler_EDF_SMP_Context Base; \ > > That last one is part of an allocation. > > > Thank you. > > > > On Sat, Jul 18, 2020 at 6:29 PM Richi Dubey <richidu...@gmail.com> > wrote: > >> > >> This information helps. Thank you. > >> > >> On Fri, Jul 17, 2020 at 6:31 PM Sebastian Huber > >> <sebastian.hu...@embedded-brains.de> wrote: > >> > > >> > On 17/07/2020 14:22, Richi Dubey wrote: > >> > > >> > > I found the line in the documentation: "Since the processor > assignment > >> > > is independent of the thread priority the processor indices may move > >> > > from one state to the other." > >> > > > >> > > This is true because the processor assignment is done by the > scheduler > >> > > and it gets to choose whether to allocate the highest priority > thread > >> > > or not. Right? So if it wants to allocate processor to the lowest > >> > > priority (max. priority number) thread, it can do so? > >> > Yes, the scheduler can use whatever criteria it wants to allocate a > >> > processor to the threads is manages. > >> > > > >> > > How is the priority of a node different from the priority of its > >> > > thread? How do these two priorities relate to each other? > >> > A thread has not only one priority. It has at least one priority per > >> > scheduler instance. With the locking protocols it may also inherit > >> > priorities of other threads. A thread has a list of trees of trees of > >> > priorities. > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
