On 22/12/2017 02:48, Cudmore, Alan P. (GSFC-5820) wrote: > I like the idea of higher performance locking and the reduced need for error > checking. We have had internal debates on how much error checking needs to be > done when locking and unlocking a mutex for a shared data structure.
Agreed, it is difficult so a mutex that does not return errors helps swing this debate. :) > > Are these new APIs in addition to the classic RTEMS APIs for similar objects? > This is a new API. My personal view is this API will become the dominate API and the classic API will be provided for compatibility. POSIX provides portability. > Since there are performance benefits, is there any reason to use the classic > API over the self-contained objects? None. > > Finally, the ticket referenced in some of the patches (2843) has a milestone > of 6.1. Are the self-contained objects going in 5.1? > It exists now. My understanding is the only thing missing is thread support but Sebastian can provide more detail here. Sebastian and I have been debating the name for the API. I not thrilled about "self-contained" as a name because it is "why it exists" not something easy and likeable and in a few years will it mean what is does when the context it currently resides in has changed. I however cannot think of anything better at this point in time. I floated 'RTEMS-X' as a name and there could be 'RTEMS Infinite', RTEMS Rapid", or something else. Also does it matter? Any suggestions? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
