On 06/06/16 14:05, Pavel Pisa wrote:
Hello Sebastian,
On Monday 06 of June 2016 13:12:52 Sebastian Huber wrote:
....
But if the RTEMS API is getting touched then in this regard I rise
again my opinion that semaphores and mutexes should be strictly
separated. This would prevent confusion and help to static code analyze
tools etc.
in general I agree.
...
That is why I suggest to separate set of SCORE and corresponding
RTEMS directives for mutexes
rtems_mutex_*
However, I would rather consider the Classic API as frozen. We should
focus on proper support for standard APIs like C11, C++11 and POSIX
threads.
In addition, for SMP the object identifier approach is useless for high
performance applications due to three reasons
I see two possible problems when actual state is unchanged
1) it would be unfortunate if the need to keep mutexes and semaphores
under rtems_semaphore would block to clean stuff and separate
these in SCORE level.
No, the Score level is fine now. Here mutexes and semaphores are
separated. In addition I entangled the different mutex variants and
moved the variant selection to the API levels. This allows more
efficient use if only a particular variant is of interest, e.g. in case
of internal mutexes (rework not yet done).
2) classic RTEMS API is used together with BSP API variants in BSPs
and drivers code. It has been (seems like) preferred API for these
areas because POSIX API has been optional and sometimes POSIX
is more verbose/complex (for example building prio. inherit mutexes
take quite more lines - preparing attributes etc.). So some simpler
primitives would be better for these areas
- it can be wrapper to pthread_mutex_ with appropriate parameters
- it can be based directly on supercore
- should not be directly C++ synchronization, C++ support should
be optional
So if the RTEMS classic API is not cleaned in mutexes respect, then there
should be some guideline which API subset should be used in BSPs,
drivers and RTEMS subsystems. Option is to use BSD directives if BSD
compatibility layer would be included in main RTEMS repo.
But even that is not ideal solution.
If classic RTEMS API is not suggested for BSPs anymore then it would
worth to convert all mainline included code to selected preferred solution.
From my point of view, classic RTEMS API is reasonable for internal
subsystems implementation. Then keeping it in shape and friendly for
automatic static code analysis is important.
So my proposal is to define rtems_mutex_ at least as direct alias
to RTEMS binary semaphore with right flags preset forces, but flags
left there for future tuning.
The next step is to implement rtems_mutex right way and teach original
rtems_semaphore to point to the right background primitive if it is
initialized with RTEMS_BINARY_SEMAPHORE.
I understand that it all is big amount of work and I cannot help
much. But it would worth to discus and find some consensus what
is a preferred direction.
Yes, its definitely worth to discuss this. My preferred solution would
be to go away from the objects and treat the Classic objects as a legacy
component. I am currently busy with the SMP implementation, so for me
this is a long term topic. It is quite labour intensive to change the
status quo, so we should be clear about a future direction before we
start with its realization.
--
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.hu...@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
