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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c3c4ae45442f569e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!g14g2000cwa.googlegroups.com!not-for-mail From: "fabio de francesco" Newsgroups: comp.lang.ada Subject: Re: Ada.Text_IO and protected objects Date: 2 May 2005 03:41:10 -0700 Organization: http://groups.google.com Message-ID: <1115030470.407204.24590@g14g2000cwa.googlegroups.com> References: <1114747457.868019.93210@f14g2000cwb.googlegroups.com> <42720DCD.6030304@mailinator.com> <4272260d$0$30463$ba620e4c@news.skynet.be> <1114811841.250745.71870@o13g2000cwo.googlegroups.com> <1s8wkzten2pnf.p7sbzkiszqsd.dlg@40tude.net> NNTP-Posting-Host: 80.181.52.213 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1115030474 21900 127.0.0.1 (2 May 2005 10:41:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 2 May 2005 10:41:14 +0000 (UTC) In-Reply-To: <1s8wkzten2pnf.p7sbzkiszqsd.dlg@40tude.net> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=80.181.52.213; posting-account=Lp02jQ0AAABMd3TAghNf0TM2YBZqD_JE Xref: g2news1.google.com comp.lang.ada:10866 Date: 2005-05-02T03:41:10-07:00 List-Id: Dmitry A. Kazakov wrote: > On 30 Apr 2005 11:07:54 +0200, Jacob Sparre Andersen wrote: > > > I am not sure if the appropriate way of handling access to > > Standard_Output is by using a protected object to manage a queue for > > transferring data to the task doing the actual writing to > > Standard_Output, or if the interaction should be through a direct > > rendezvous with the task doing the actual writing to Standard_Output. > > #3: It can be also done on the context of the same task using a protected > object implementing a mutex. A controlled object is then used for safe > mutex access. > > But a monitor task (the second variant you mention) is cleaner and safer in > my view. It might be slightly slower than mutexes, though that should > depend on the compiler-platform. Thank all of you. I have thought a while about the need to start a third task to do the actual writing to Standard_Output as the second variant mentions. I decided not to do it because the original problem is to manage two different printer devices or output files, one at each door. Otherwise there wouldn't be any need two have two different tasks to emit tickets, only one would suffice. (I hope I am not missing something...) Anyway just to reason on the solution Dmitry and Jacob suggest, how would you implement that one? If I have understood there would be the need for a third task in charge to handle IO. I suppose it means that the other two tasks have to emit "tickets" to a protected queue that would be later read by the third task in order to print them. Is it what you mean? How can we assure that all elements in queue are ordered by increasing numbers if any of the previous two tasks add tickets to this queue at random times? I think there must be something I didn't catch. I am not even sure you were proposing a queue working in terms I explained here. Can you make your solution clearer for me, please? Regards, fabio de francesco > > > There is a "dining philosophers" example available somewhere on the > > web (written by Feldman, I think), where you probably can find a good > > example of how to solve the combination of tasking and IO. > > Dining philosophers is rather an example of why mutexes/semaphores are > dangerous (deadlock) and low-level and what could be done about that. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de