From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,722530427d626919 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-12 02:20:17 PST Path: supernews.google.com!sn-xit-02!supernews.com!newsfeed.mesh.ad.jp!fr.clara.net!NiOuZphide.fr.clara.net!teaser.fr!enst!enst.fr!not-for-mail From: "Beard, Frank" Newsgroups: comp.lang.ada Subject: RE: Protected Type Question. Date: Tue, 12 Dec 2000 00:49:42 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: avanie.enst.fr 976616416 55050 137.194.161.2 (12 Dec 2000 10:20:16 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Tue, 12 Dec 2000 10:20:16 +0000 (UTC) To: "'comp.lang.ada@ada.eu.org'" Return-Path: X-Mailer: Internet Mail Service (5.5.2448.0) Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: comp.lang.ada mail<->news gateway Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: supernews.google.com comp.lang.ada:2985 Date: 2000-12-12T00:49:42-05:00 > 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