Hello Sebastian,
On Wednesday 28 of September 2016 11:06:19 Sebastian Huber wrote:
> On 28/09/16 10:47, Sebastian Huber wrote:
> > On 28/09/16 10:38, Pavel Pisa wrote:
> >> 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.
> >
> > the name "self-contained" is used for objects which work with a user
> > supplied storage. For example:
> >
> > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib
> >/libc/sys/rtems/include/sys/lock.h;h=c261adf681e542af945969149f6533248eb06
> >fd6;hb=HEAD
> >
> >
> > In contrast to the Classic and POSIX objects which work with a kernel
> > supplied storage which is accessed via the object identifier.
> >
> > In the context of the Newlib <sys/lock.h> a "semaphore" is a counting
> > semaphore.
>
> In case the name "self-contained" is confusing for this purpose, then I
> am happy to replace it with a better alternative.
No, I like self-contained, I have no problem with that. It describes
how it works. I have problem with SEMPAHORE part because
it associates for me with IPC/inter thread even delivery, producer
consumer pattern. Not mutual exclusion of enter to given code.
Excuse for confussing specification of the naming note.
Best wishes,
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
