Re: Is Text_IO.Put_Line() thread-safe?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 14.06.12 23:37, Robert A Duff wrote:
> awdorrin<awdorrin@gmail.com>  writes:
>
>> That is what I mean, if the Text_IO.Put_Line isn't thread-safe, and
>> its picking up data from the array being sorted in the other thread,
>> and printing it, then it very well could have written the information
>> it was supposed to be printing to the screen, into that array that was
>> being sorted... Anything could be corrupted.
>
> Yes.  It doesn't seem likely to me, but it could happen.
> More likely (I'm guessing) is that there's another bug, somewhere
> other than the Put_Lines.
>
>> I really cannot believe that the Put_Line's aren't thread safe.
>
> Yes, there are several things wrong with the design of Text_IO,
> and this is one of them.  But it's not too hard to work around it.

But surely I/O routines in general should  not be thread safe
and thus have to drag in everything required to achieve thread
safety?

The result is still likely not safe, after all, if one can duplicate
file descriptors, or is unaware of others writing to the same file,
such as a log file. Neither does the thread safety of single Text_IO
calls make sequences of Text_IO calls behave atomically.  Assuming
Num_IO.Put and New_Line to be thread safe,

   Num_IO.Put (123);  -- (1)
   New_Line;  -- (2)

What has happened between (1) and (2)?

An atomic sequence in a dedicated I/O task looks just right to me.

A program sprinkled with I/O calls because, well, they are
thread safe, is a good predictor of maintenance nightmares,
as it lacks modularity and separation of concerns.