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-Thread: 103376,534dd301375921ac X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.220.230 with SMTP id pz6mr7510775pbc.3.1339795638447; Fri, 15 Jun 2012 14:27:18 -0700 (PDT) Path: l9ni54934pbj.0!nntp.google.com!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Is Text_IO.Put_Line() thread-safe? Date: Fri, 15 Jun 2012 17:27:14 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <93201f1a-d668-485e-83b4-492bc283f36e@googlegroups.com> <546fc310-c898-417a-9c92-a5b12ef32591@googlegroups.com> <4fdac8dc$0$9508$9b4e6d93@newsspool1.arcor-online.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 X-Trace: pcls6.std.com 1339795637 24318 192.74.137.71 (15 Jun 2012 21:27:17 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 15 Jun 2012 21:27:17 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:Bn0CjcSfJ/AuJL8UZgMZ0zTPIbg= Content-Type: text/plain; charset=us-ascii Date: 2012-06-15T17:27:14-04:00 List-Id: Georg Bauhaus 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