comp.lang.ada
 help / color / mirror / Atom feed
From: "Beard, Frank" <beardf@spawar.navy.mil>
To: "'comp.lang.ada@ada.eu.org'" <comp.lang.ada@ada.eu.org>
Subject: RE: Protected Type Question.
Date: Tue, 12 Dec 2000 00:49:42 -0500
Date: 2000-12-12T00:49:42-05:00	[thread overview]
Message-ID: <B6A1A9B09E52D31183ED00A0C9E0888C469935@nctswashxchg.nctswash.navy.mil> (raw)

> 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.

I'm well aware of the danger, and I totally
agree that when at all possible the synchronization
should be done at a higher level.  That's exactly
the way it is done in other parts of our code.
The only reason I'm trying the "semaphore" approach
here is I was told on the ObjectAda list-server that
Unchecked_Deallocation is potentially blocking,
so it shouldn't be called from within a protected
type.  Delete and New_String used to be protected
operations.  The Delete code contains calls to a
garbage collector (with a limit).  When the limit
is reached, Unchecked_Deallocation is called.
If it is true, that it is potentially blocking,
then I have to go with the "semaphore" 
approach, or use another task (which I was
trying to avoid).

Is Unchecked_Deallocation, or "new" for that
matter, potentially blocking?

> 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 :-)

I'm not trying to use semaphores for task
synchronization in the classic sense, only to
protect the garbage collector.  The tasks pass
messages through the system using protected queues.
The Get and Put methods are protected operations.
The Input task receives a message, parses it, determines
where it goes, and places it on the respective 
protected queue.  Each of the different processing
tasks handle a different type of message.  If
any of the processing tasks determine that a
message contains errors, they place the erred message
on the protected Error_Queue for the Error_Task.
The Error_Task interacts with a special table in the
database where messages are corrected by an operator
through a GUI and sent back into the system.
Once an erred message is corrected it is processed
or placed on the Output_Buffer where the Output_Task
sends it back out through the network.

It just so happens that every task in the system,
either directly or through calls to other classes,
uses the Byte_String_Class to build or process
the message objects that also happens to contain
byte strings as components.  Byte_String_Class is
just a class that contains a Byte_String_Object
which is just a fancy pointer to a Byte_Array
that is used for all kinds of stuff.  The same
way you would use Ada.Strings.Unbounded
Unbounded_String.  It just happens to also be
a component of the message object.

And before anyone asks why we are not using
Unbounded_String, it is because we are trying to
figure out why Unbounded_String started failing.
Unbounded_Strings are released by setting them
to Null_String.  There was no protected type 
involved (unless Unbounded_String is also a
protected type).  The tasks were using the
Unbounded_Strings, then setting them to Null_String.
Somewhere along the line, after running for a
long time, the Unbounded_Strings suddenly have
residual data in them, as if the memory was 
picked up before the runtime cleared it.
So, I was looking for a way to switch to our
dynamic string class, which I know needs 
protection.

I hope this makes things clearer.
Any help is greatly appreciated.

Frank




             reply	other threads:[~2000-12-12  5:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-12  5:49 Beard, Frank [this message]
2000-12-12 10:54 ` Protected Type Question Robert Dewar
  -- strict thread matches above, loose matches on Subject: below --
2004-01-03 20:58 protected type question shoko
2004-01-04  0:50 ` James Rogers
2004-01-04  1:04 ` Robert I. Eachus
2000-12-13 23:23 Protected Type Question Beard, Frank
2000-12-12  6:43 Beard, Frank
     [not found] <B6A1A9B09E52D31183ED00A0C9E0888C46992F@nctswashxchg.nctswash.navy.mil>
2000-12-12  3:39 ` tmoran
2000-12-12  1:45 Beard, Frank
2000-12-12  2:51 ` Robert Dewar
1996-03-20  0:00 Bill Pritchett
1996-03-20  0:00 ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox