Applying an operation to a set of threads in RTEMS

Utkarsh Rai utkarsh.rai60 at gmail.com
Fri Jul 3 04:37:15 UTC 2020


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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200703/5883f378/attachment.html>


More information about the devel mailing list