Misc on RBTree Thread Queue Priority Discipline Changes

[Joel Sherrill]

On 7/9/2014 10:34 AM, Gedare Bloom wrote:
> On Tue, Jul 8, 2014 at 5:37 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>> Hi
>>
>> If you take the patches in their entirety, most of the tests
>> appear to be about 500 bytes smaller on the erc32.
>>
> What is the change in wkspace size? Basically you add 3 pointers +
> enum to each TCB / thd proxy, but remove some space for the control
> node I guess. I would guess the code savings is worth it.
Good question. I was watching code space. :)

Before:

(gdb) p sizeof(Thread_queue_Control)
$1 = 64
(gdb) p sizeof(Thread_Control)
$2 = 360

After:

(gdb) p sizeof(Thread_queue_Control)
$1 = 40
(gdb) p sizeof(Thread_Control)
$2 = 376

Summary:

-24 Thread_queue_Control
+16 Thread_Control

Since thread queues are used in blocking objects, I assume
there will be more of them in a system and this is a net win.

Technically, they could be used in the Scheduler implementations.
When a thread is not blocked, the RBTree_Node is unused.
>> None of the tmtests do priority based blocking so I can't
>> report any changes there.
>>
>> There was historically a subroutine in the threadq calls for a discipline
>> specific routine. Using the RBTree, this resulted in only 3-5 lines
>> of code unique to the discipline in those discipline files. The other
>> 20+ lines was duplicated. The last patch folds those subroutines into
>> the main methods.
>>
>> There is still some room for clean up since the code that is in
>> threadblockingoperationcancel.c is open coded there and
>> three other places. So there are a total of four copies of this
>> code in the tree.
>>
>> + rtems/src/eventsurrender.c
>> + score/src/threadqdequeue.c
>> + score/src/threadqextract.c
>> + score/src/threadblockingoperationcancel.c
>>
> I do not see discipline used in threadblockingoperationcancel.c what
> do you mean?
All four of those methods do exactly the same thing AFTER they
deal with the event or threadq specific discipline code. I
have a patch pending with this change.
>> Two of those need the debug check code and two do not.
>> Also the method name isn't right for all four cases. It indicates
>> its use on the "resource released in ISR" usage not the
>> normal "clean up from blocking" case.
>>
>> Suggestions on a new name and whether this should be
>> a real subroutine or a static inline is appreciated. Then I
>> can rework and reduce the code duplication.
>>
> Propose the code; I'm not sure what you mean to refactor into the new function.
I found a solution and will pose a patch. Two methods. The one
used for undoing on a sync state trigger will be a wrapper for the
one used for normal unblocking.
> -Gedare
>
>> --
>> Joel Sherrill, Ph.D.             Director of Research & Development
>> joel.sherrill at OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available                (256) 722-9985
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985