On 17/12/16 3:26 am, Sebastian Huber wrote: > > > On 15/12/16 23:34, Chris Johns wrote: >> On 15/12/2016 18:02, Sebastian Huber wrote: >>> On 14/12/16 22:15, Chris Johns wrote: >>>> On 15/12/2016 00:39, Sebastian Huber wrote: > [...] >>>> Would the "tiny" footprint be smaller if all internal services >>>> including compiler thread support are made C11? Could this actually be >>>> done? Parts of POSIX has been creeping in over time so the position is >>>> a little confused at the moment. I am not sure about a bits and pieces >>>> approach, maybe a full switch is made. >>> >>> Yes, the footprint would be smaller. If we provide self-contained >>> threads, then the footprint would be much smaller, e.g. no object >>> administration, no heap. >> >> Great. This is a powerful reason to look at moving in this direction >> and removing the remaining POSIX usage in libstdthreads. >> >> A brief audit of rtems.git shows the change is possible with less than >> 30 Classic task creates and a similar number of semaphore creates so a >> full change look reachable which is nice. >> >> Should we look at moving all internal services to C11 and standardise >> it? I think there is value in doing this. It can be a post 4.12 branch >> activity. > > In contrast to the C11 mutexes, I don't see a real value in moving from > Classic API tasks to C11 threads. The Classic API you have more control > over task attributes, modes, priority, stack size, etc.
As an interim solution this is possible but we should consider and plan the long term solution. I took a closer look at C11 threads and see the thread support is not suitable. I have concerns about mixing the API to get a "tiny" image and was hoping a single API could do this, ie the attributes of the API should be consistent across all calls and meet a minimum set of required functionality. The lack of thread attributes raises a difficult issue we need to consider a little more. I do not like the idea of a thread created with thrd_create and then needing attributes set by the another API. I thinking mixing is an architecturally poor path to follow. The C11 mutex is thin and the storage model is attractive. The FreeBSD man page for C11 functions states: As of ISO/IEC 9899:2011 (``ISO C11''), the C standard includes an API for writing multithreaded applications. Since POSIX.1 already includes a threading API that is used by virtually any multithreaded application, the interface provided by the C standard can be considered superfluous. Should we be looking at the POSIX interface and doing this work there? That is move the POSIX implementation away from the RTEMS object model. Could this be done and would the same mutex performance be achieved? If the same storage model and performance can be gained with POSIX why not look at moving in this direction. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
