RE: Protected Type Question.

[Robert Dewar <robert_dewar@my-deja.com>]

In article
<B6A1A9B09E52D31183ED00A0C9E0888C469931@nctswashxchg.nctswash.na
vy.mil>,
  comp.lang.ada@ada.eu.org wrote:
> Concerning your comment
> "and is very poor programming style".
> Since it is taken directly from the LRM,
> are you saying the LRM is written in
> poor programming style?  The fact that I
> split it into a package spec and body
> is poor programming style?  Elaborate
> please.

The example in the RM is intended to illustrate
the semantics of protected types. Since everyone
is assumed to be familiar with simple semaphores
(even though they are a deprecated form of
synchronization), this example is good for the
purpose of illustration, but that does not mean
that you should assume this code is useful in
a given situation. The examples in the RM are
all for the purposes of helping people understand
the syntax and semantics of Ada, they are not
intended as suggestions for what you should
actually write in programs.

> Concerning, "though of course no one would
> use it in the form given (it is obviously
> subject to priority inversion".  Our system
> is a message correction system that is not
> required to be real-time, other than it can't
> be too slow.  All our tasks are at the same
> priority so there isn't any inversion.  But
> for argument's sake, lets say I need this type
> of "semaphore" for protecting critical regions
> within a system that contains prioritized tasks.
> What would be your suggestion for "correcting"
> the form so that is not subject to priority
> inversion and bad programming style?

Well there are many many ways to organize task
synchronization. Most likely if you have no
real time requirements, you can use classical
rendezvous style and end up with something
that is FAR safer and easier to read and
maintain. One of the other dangers of semaphores
is that you can forget to claim or release, causing
chaos, or indeed forget both, resulting in race
conditions. By synchronizing at a higher
structural level, these dangers are avoided.

Any good Ada book will discuss the general
topic of synchronization and design. Burns and
Welling is a useful source of more detailed

> design suggestions, but there are many sources.
> I don't want insults, I want assistance.  If
> I can offer something to someone less
> experienced or less knowledgeable, I try to do
> so, and hopefully with a little more mercy.

No one is insulting anyone, I just made the
technical comment that semaphores are NOT the
preferred form of task synchronization these
days, and to use protected types to implement
semaphores is definitely an example of
abstraction inversion. These are hardly
contentious points of view :-)

> Anyone can say something is lousy, but few
> can offer a better way.  Which one are you?
> Which one do you want to be?

There is no way to answer to how you should
do things, given that you gave no hint at all
of what your problem structure is. You would
have done better using some of your energy in
writing your long answer to describe what your
problem is!

We can't offer help if we don't know what you
are trying to do.




Sent via Deja.com http://www.deja.com/
Before you buy.