Hello Sebastian and Gedare,
I cannot hold myself to not express my opinion there.
On Wednesday 28 of September 2016 07:52:51 Sebastian Huber wrote:
> On 27/09/16 16:59, Gedare Bloom wrote:
> > A mostly unrelated question: why do we have two different
> > _Semaphore_Get functions, one static in score/src/semaphore.c and the
> > other inlined from semimpl.h?
>
> Yes, this is a bit confusing. One is part of the Classic API, the other
> is for the self-contained semaphores.
what is the reason to name these self-contained semaphores.
If they cannot be used as signaling mechanism between threads,
then they should be called mutexes to clearly state,
that the only valid use is initialize it as full,
gain and release it from the same thread.
For me, even use of simple, full binary etc.. semaphores
in the classic RTEMS API is a problem. There is semaphore
and mutex and each has different semantic and rules.
I understand, that historically semaphore has more meaning
as the way to pass only one task or limited number of tasks
to given part of the road, but today meaning is settled.
So if the self-contained x cannot be used to signal event
between threads then it is mutex. If there is plan to
use self-contained x even like futex/conditional variable
etc., then situation is more complex and it has reason
to have some naming layer working with semaphore or futex
stem but programmer should get clear mutex named primitives
at the end. Which is what POSIX does. Linux kernel internal
APIs cured this confusion some time ago as well.
And even rtems_* API should include mutex operations.
It is clear and it is not necessary to complicate
documentation then what is allowed and what is not
with each semaphore flags combination.
Best wishes,
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
