This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ API Reference manual


On Monday 12 August 2002 07:53, Nick Garnett wrote:
> NavEcos <ecos@navosha.com> writes:
> > The reason I started reading it is because I noticed that there
> > is additional functionality in the C++ interface not available in
> > the C interface, for example getting a thread's name or walking
> > through all the threads to check for stack usage, and other
> > nifty things.
>
> These things are mostly there to aid GDB and other debugging
> features. I cannot immediately think of any use an application would
> have for them.

Profiling of the code is one.  I've done a bit of work with vxWorks
and there is a lot of potentional to make an environment that is
as good or even superior to vxWorks.

BTW, Insight is already better than vxWorks' gdb implementation
at least under x86.

> > The binary semaphore is probably one of the most useful constructs
> > that is available in C++ but not in C.  I emulated one with a counting
> > semaphore but the implementation was a bit sloppy.
>
> A binary semaphore is exactly equivalent to a counting semaphore that
> has an initial value of 1. It was decided to not export the binary
> semaphores via the C API in the interests of simplicity. The C API was
> never intended to be a complete representation of the kernel C++ API,
> merely a sufficient and consistent subset -- in the same way the POSIX
> and uITRON APIs are.

A binary semaphore isn't exactly equivalent to a counting semaphore
because the count can never go beyond 1 with a binary semaphore -
you can verify this by looking at the class definition of
Cyg_Binary_Semaphore in sema.hxx

I have had to support binary semaphores when porting code from
one OS to another - that is why I needed a binary semaphore.
When you don't have to port though, I think flags work just fine
if not better than a binary semaphore for most cases.

> > I am considering adding a message queue, i.e. a variable sized
> > message box.  Currently I have it implemented with two counting
> > semaphores.  If I were to modify it to use signals would you be
> > willing to incorporate it into the main tree?  I think many people
> > would find this useful, not just me.
>
> We already have the Cyg_Mqueue class that implements a more dynamic
> form of message passing than the mailbox class. Also, mailboxes
> currently implement a message queue whose size is fixed at compile
> time. If this is insufficient then the best next step is to extend the
> implementation of mailboxes to allow a runtime supplied buffer of any
> size to be used. Obviously some care has to be taken to make this
> backward compatible and configurable.

I haven't run into Cyg_Mqueue I do not think.  I will study and
document it.

I will look into extending the mbox to implement dynamic sizes also.

Thank you for the tips,
-Rich

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]