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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a046ce7f5ee1fa51 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-05 10:16:50 PST Message-ID: <3DEF96D4.7060903@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: new_line in a put_line References: <1ec946d1.0212020657.2bd8b5c@posting.google.com> <3DEE33A5.8080709@acm.org> <3DEE3ED2.7070009@cogeco.ca> <3DEEAC52.5000906@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Dec 2002 13:11:32 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1039111894 198.96.47.195 (Thu, 05 Dec 2002 13:11:34 EST) NNTP-Posting-Date: Thu, 05 Dec 2002 13:11:34 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:31470 Date: 2002-12-05T13:11:32-05:00 List-Id: Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> The Rendezvous has the benefit that the request to perform output >> is queued. This results in greater efficiency on most platforms >> because it avoids having threads wake up and test to see if they >> won out on the condition variable set (protected object). > > I think you're mistaken. After performing a protected procedure or > entry, it's perfectly legal for the same task to check the barriers of > the object. I don't know about implementations, but this is certainly > intended behavior for protected objects. Thus, tasks don't have to "wake > up" until they are ready to run. When you look behind the scenes at the _implementation_, for some platforms (for some UNIX at least), these things boil down to pthread calls. For example: http://www.cs.nmsu.edu/~jcook/Tools/pthreads/pthread_cond.html says : int pthread_cond_signal (pthread_cond_t *cond); This wakes up at least one thread blocked on the condition variable. Remember that they must each re-acquire the mutex before they can return, so they will exit the block one at a time. So if pthread_cond_signal() is used at all in the implementation of a protected object, you will have (on many platforms) the possibility that a number of threads awaken to see if they "won". On some UNIX platforms this is a serious issue when you have 500+ threads (this is similar to the UNIX problem of 500+ processes waking up when a semaphore gets notified -- believe it or not, on many platforms, all processes unswap to see if they "won", leading to serious performance problems [e.g. HPUX].) Now whether this is better or worse than rendezvous, is open to implementation also. I do know that for pthread supported platforms, GNAT does use pthread_cond_signal and pthread_cond_wait, which are open to the problems presented (see the source file for system.task_primitives.operations.adb). The O/S will determine whether or not one or multiple threads awaken however (it might be that Linux queues them for example). But if you are taking portability into mind, you should assume that all threads awaken (only one will stay awake of course, because only one thread can win -- like the movie "Highlander" -- "there can only be one"). ;-) Is the rendezvous better? I don't know, because I didn't dig that closely into the sources. But potentially, I would think that with a queue being used, it could be implemented such that only the task on the front of the queue gets "signalled" to continue (each task would then need its own "condition variable"). >> It also guarantees "order". With the protected object approach a >> "Johnnie come lately" task could gain access while already blocked >> tasks are waiting to gain access -- destroying the waiting line >> sequence. This may create some confusing to read "output". > > > If you need to guarantee order for a protected operation it should be an > entry. This guarantees the same order as for a task entry. OK then, this makes the distinction between rendezvous and protected objects unimportant in the "ordering" context. It also probably kills the "efficiency" debate, because I would assume that the same implmentation would be used for both. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg