Re: new_line in a put_line

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

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