<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Can someone help clarify the issue?<div class=""><br class=""></div><div class="">Is this a “required compiler to build RTEMS” question? That is, are the compilers currently required to build the RTEMS Sebastian modified guaranteed to support C11 mutexes, and is it desirable to be more conservative about what compiler is needed?<div class=""><br class=""></div><div class="">If C11 mutexes guarantee what Sebastian needs and unknown compiler support isn’t required then allow it.</div><div class=""><br class=""></div><div class="">Note that I haven’t researched this, I’m just guessing that the C11 mutexes may guarantee less than the classic semaphores, and are being implemented at the compiler level, and that this minimum level of compiler support is OK for building RTEMS.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 14, 2016, at 16:15 , Chris Johns <<a href="mailto:chrisj@rtems.org" class="">chrisj@rtems.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 15/12/2016 00:39, Sebastian Huber wrote:<br class=""><blockquote type="cite" class="">Use C11 mutexes instead of Classic semaphores as a performance<br class="">optimization and to simplify the application configuration.<br class=""></blockquote><br class="">The use of C11 mutexes has not been agreed too and we need to discuss <br class="">this in more detail before we allow use within RTEMS. I would like to <br class="">see positive agreement from all core maintainers before this and similar <br class="">patches can be merged.<br class=""><br class="">RTEMS has required the use of the Classic API because:<br class=""><br class=""> 1. Available on all architectures, BSPs and tool sets.<br class=""> 2. Always present in a build.<br class=""> 3. Was considered faster than POSIX.<br class=""><br class="">The Classic API provides a base level of required functionality because <br class="">it is always available in supported tool sets and leads to the smallest <br class="">footprint because we do not need to link in more than one API.<br class=""><br class="">I understand things change and move on so it is great to see this change <br class="">being proposed and our existing base line being challenged.<br class=""><br class="">I see from your performance figures C11 mutexes are better and the <br class="">resources are allocated as needed and used which is a better model than <br class="">the Classic API's configuration table. This is nice.<br class=""><br class="">Do all architectures and BSPs have working C11 support?<br class=""><br class="">Is there tests in the RTEMS testsuite for C11 threading services?<br class=""><br class="">What target resources are used to support this API, ie code and RAM usage?<br class=""><br class="">Would the "tiny" footprint be smaller if all internal services including <br class="">compiler thread support are made C11? Could this actually be done? Parts <br class="">of POSIX has been creeping in over time so the position is a little <br class="">confused at the moment. I am not sure about a bits and pieces approach, <br class="">maybe a full switch is made.<br class=""><br class="">Does C11 work on LLVM (I hear support is close)?<br class=""><br class="">Where is the C11 API implemented? Is the threading code outside the <br class="">RTEMS source tree and what effect does that have on those looking to <br class="">certify RTEMS?<br class=""><br class="">Does a change like this require a coding standard update?<br class=""><br class="">Chris<br class="">_______________________________________________<br class="">devel mailing list<br class=""><a href="mailto:devel@rtems.org" class="">devel@rtems.org</a><br class="">http://lists.rtems.org/mailman/listinfo/devel<br class=""></div></div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;">Peter<br class="">-----------------<br class="">Peter Dufault<br class="">HD Associates, Inc. Software and System Engineering</span></font></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><br class=""></span></font></div>This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication.</span></div></span></div></div></div></div></div></div></div>
</div>
<br class=""></div></div></body></html>