Self-contained POSIX synchronization objects for RTEMS 4.12?

[Chris Johns]

On 20/9/17 3:48 pm, Sebastian Huber wrote:
> 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. 

Yes I agree some of these are useful and I am not against mechanisms being added
to allow support however I feel grouping support that is consider user friendly
under RTEMS_DEBUG is bending it's usage and leaves the user in an awkward
position of leaving the option on or off for production.

Adding more compile options increases the time we need to spent testing the
combinations. A rtems-bsp-builder run with `--profile=everything --build=all`
has 1552 separate builds and 2.2M object files and took almost 7hr on a fast
machine. That is 16 seconds a BSP on average.

I am not offering a solution here, just raising the issues I see. How we name
this is important.

> A correct application doesn't need these checks
> and simply encounters a run-time penalty and some space overhead, but it should
> be tolerable.

That is true if what is controlled by the switch is what we say it is. This
becomes a key issue for anyone auditing the code.

> However, some internal consistency checks, e.g. for the SMP locks,
> are quite heavy weight and really hurt the performance.

Understood.

> From my experience SMP applications are quite sensitive to the performance of
> mutexes. For example, the glibc POSIX mutex is heavily performance optimized,

Agreed.

Chris