On 7/9/2014 10:34 AM, Gedare Bloom wrote: > On Tue, Jul 8, 2014 at 5:37 PM, Joel Sherrill <joel.sherr...@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.sherr...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
