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.
> On Jul 3, 2020, at 08:42 , dufa...@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.ra...@gmail.com> wrote: >> >> >> >> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault <dufa...@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@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
