Self-contained POSIX synchronization objects for RTEMS 4.12?

[Sebastian Huber]

On 20/09/17 02:47, Chris Johns wrote:

> On 20/09/2017 03:43, Sebastian Huber wrote:
> [...]
>>   So, making these checks RTEMS_DEBUG dependent is something worth considering.  Maybe we need a RTEMS_ROBUST option focusing on user introduced errors.  RTEMS_DEBUG enables a lot of internal consistency checks.
> I see a contradiction here. If a debug configured environment and specifically a
> kernel you test to validate all is ok is not a production environment then your
> testing is only helpful. Changing the environment, ie the kernel without debug
> on, invalidates the previous testing. Any change without a careful and precise
> audit must be treated as a change. This leaves our users with an awkward
> question "Should debugging or robust settings be left on for production?". If
> all testing shows the system is working and performing to specification why turn
> the settings off? If there is any doubt with that last question it must relate
> to the tests and the collected results.
>
> I wonder if there is a case of looking to hard, for example I could see a case
> where you extrapolate this argument to removing malloc NULL checks in
> production, after all the memory is fixed, the initialisation is always the same
> and malloc will never fail !! It is what you do not see not what you see that
> you need to cater for.
>
> I view RTEMS_DEBUG as a develop aid for those working within RTEMS. It should
> only relate to internal consistency checks.
>
> I view RTEMS_ROBUST as dangerous, is RTEMS not robust if I do not use it?
>

There are some checks that help to debug broken applications. For 
example the heap protection, the deadlock detection, the file descriptor 
reference counting and simple parameter validation. A correct 
application doesn't need these checks and simply encounters a run-time 
penalty and some space overhead, but it should be tolerable. However, 
some internal consistency checks, e.g. for the SMP locks, are quite 
heavy weight and really hurt the performance.

 From my experience SMP applications are quite sensitive to the 
performance of mutexes. For example, the glibc POSIX mutex is heavily 
performance optimized, however, we still have a specialized mutex for 
libgomp (the GCC OpenMP run-time support):

https://gcc.gnu.org/viewcvs/gcc/trunk/libgomp/config/linux/mutex.h?view=markup

This implementation would work also on RTEMS by the way. It offers only 
random fairness, so this is not a real-time synchronization primitive.

-- 
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.