Applying an operation to a set of threads in RTEMS

dufault at hda.com dufault at hda.com
Fri Jul 3 12:42:23 UTC 2020


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.



More information about the devel mailing list