----- Cudmore, Alan P. (GSFC-5820) <alan.p.cudm...@nasa.gov> schrieb: > Interesting. On our 40Mhz Coldfire CPU, one of our developers did note how > the RTEMS semaphore calls were slow.
It would be quite interesting if you could run the tmtests with your version and the current Git master. The new tmfine01 tests some Classic API as well as self-contained objects operations. > > So currently the self-contained objects are more efficient, but do not > provide as many real-time features. The self-contained mutexes use the priority inheritance protocol (or OMIP in case of SMP). There is no arbitrary limits, its just a matter of defining and implementing the APIs. The difficult part to enable self-contained objects in principle is already done (it was several weeks of work). > Your changes to convert the POSIX objects to self-contained would help > improve the efficiency of POSIX synchronization objects, but a few Classic > RTEMS APIs may still be needed. > > If I could rank them: > RTEMS Classic API – most feature complete for real time systems, least > standard, least efficient > POSIX API – somewhat feature complete for real time systems, somewhat > standard, more efficient with self-contained changes > C11, C++11, OpenMP – Not as feature complete, most standard, most efficient > Does that make sense? > > Would the POSIX synchronization objects be as efficient as C11 objects once > converted to be self-contained? The problem with POSIX mutexes is that they are available in different variants. The actual variant is defined by attributes during object creation. You always have a switch case or function pointer overhead (not a big overhead, but still an overhead). -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
