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

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

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

Yes, I suppose I agree that the programmer should have the option
of thread-UNsafety.  But here, we're talking about writing to
standard output.  And debug output at that.  Surely there should
be a convenient way to do that without horsing around with extra
tasks and whatnot.  Surely that should be the default.

> 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)?

Right.  That's one of the things I don't like about this design.
You should be able to write your entire "message" in a single call
and (at least optionally) make that call atomic.  The "message" could
be multiple lines, which Text_IO doesn't support at all.

The C printf style seems more convenient to me.  You write a template,
and fill in the "blanks" with variable data, formatted.  Printf is
too complicated, and not type safe, but those things could be
fixed in a different language.  The basic idea of a fill-in-the-blanks
template is a good one.

In Ada, you can do:

    Put_Line("Count = " & Integer'Image(Count));

but that has problems.

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

Maybe, but whatever the mechanism, it ought to be provided to
the programmer by the language.

Anyway, it has the same problem as your example above -- multiple
invocations of the entry are not atomic.  There's no getting around
that -- as soon as you have multiple tasks writing to the same file,
you have to decide on the granularity of the atomicity.

> 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.

I agree that it's usually a good idea to separate I/O from
other processing.

- Bob