<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 4, 2020 at 1:13 AM <<a href="mailto:dufault@hda.com">dufault@hda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
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.<br>
<br></blockquote><div><br></div><div>Oh, that makes more sense. Thank you for the clarification! </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On Jul 3, 2020, at 08:42 , <a href="mailto:dufault@hda.com" target="_blank">dufault@hda.com</a> wrote:<br>
> <br>
> My thought is that it matches what is needed and is expected to be optimized.<br>
> <br>
>> On Jul 3, 2020, at 24:37 , Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
>> <br>
>> <br>
>> <br>
>> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault <<a href="mailto:dufault@hda.com" target="_blank">dufault@hda.com</a>> wrote:<br>
>> 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.<br>
>> 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.<br>
>> <br>
>> <br>
>> 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()?<br>
>> <br>
>> Using FD_SET and friends for specifying thread access could be a good model to specify which threads need access to which thread.<br>
>> <br>
>> 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'. <br>
>> <br>
>> However, it won't scale infinitely.  Linked lists won't scale infinitely in real-time either.<br>
>> <br>
>> 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.<br>
>> <br>
>> Peter<br>
>> -----------------<br>
>> Peter Dufault<br>
>> HD Associates, Inc.      Software and System Engineering<br>
>> <br>
>> This email is delivered through the public internet using protocols subject to interception and tampering.<br>
>> <br>
> <br>
> Peter<br>
> -----------------<br>
> Peter Dufault<br>
> HD Associates, Inc.      Software and System Engineering<br>
> <br>
> This email is delivered through the public internet using protocols subject to interception and tampering.<br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<br>
Peter<br>
-----------------<br>
Peter Dufault<br>
HD Associates, Inc.      Software and System Engineering<br>
<br>
This email is delivered through the public internet using protocols subject to interception and tampering.<br>
<br>
</blockquote></div></div>