Applying an operation to a set of threads in RTEMS

[Utkarsh Rai]

On Sat, Jul 4, 2020 at 1:13 AM <dufault at hda.com> wrote:

> This thought is intended to be evaluated, not adopted.  What I meant was I
> think you have a "bitmask" of threads that need access to a stack that is
> similar to a "bitmask" of threads/processes that may be blocked in select.
> The select-mask is a major focus across operating systems.  That's why I
> thought that if you consider it to be equivalent you should use that
> interface.
>
>
Oh, that makes more sense. Thank you for the clarification!

> On Jul 3, 2020, at 08:42 , dufault at hda.com wrote:
> >
> > My thought is that it matches what is needed and is expected to be
> optimized.
> >
> >> On Jul 3, 2020, at 24:37 , Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
> >>
> >>
> >>
> >> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault <dufault at hda.com> wrote:
> >> I finally have gotten to reviewing Utkarsh's work in GSOC.  One item
> that I don't like is that there is a linked list management of the threads
> that have access to the stack.
> >> I think this access is similar to the file descriptors that are blocked
> in a select call.  On a given architecture I don't know exactly how many
> file descriptors I can block, I don't know exactly what the FD_SET macro
> does, but I have access to multiple file descriptors through the FD_*
> macros.
> >>
> >>
> >> Hello, thank you for the feedback. If I understand your suggestion
> correctly, we can specify a file descriptor set 'fd_set' and then register
> the stack attributes to this set, and then check for the 'current stack'
> through select() and FD_ISSET()?
> >>
> >> Using FD_SET and friends for specifying thread access could be a good
> model to specify which threads need access to which thread.
> >>
> >> My question is,  what benefit do we get by using FD_SET and friends?
> Ultimately we will have to iterate through the set to check for the
> 'current stack'.
> >>
> >> However, it won't scale infinitely.  Linked lists won't scale
> infinitely in real-time either.
> >>
> >> An optimization that I had in mind was to use the LRU model. This way
> we can mark the stack attributes of the last thread as 'not current'
> without iterating through the list or the set.
> >>
> >> Peter
> >> -----------------
> >> Peter Dufault
> >> HD Associates, Inc.      Software and System Engineering
> >>
> >> This email is delivered through the public internet using protocols
> subject to interception and tampering.
> >>
> >
> > Peter
> > -----------------
> > Peter Dufault
> > HD Associates, Inc.      Software and System Engineering
> >
> > This email is delivered through the public internet using protocols
> subject to interception and tampering.
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200704/d0a5a086/attachment.html>