Is Text_IO.Put_Line() thread-safe?

[awdorrin]

I tried posting this yesterday, but my browser glitched out on me, looks like it posted a partial message (which I have tried to delete.)

First some background:

I'm migrating legacy code to Linux, using GCC/GNAT 4.4.5-8. The legacy code is a mix of C and Ada. The C code kicks off multiple POSIX threads (around 20), some of which are Ada code and others which are C. (Complicating that, some Ada calls imported C and some C calls imported Ada.)

One module is called 'Common' and is a central 'shared memory' location. The other modules will call functions in Common to request chunks of memory in which to store data structures.

As the modules initialize themselves, they call another routine in Common to wait until all tasks are ready (basically there is an array defined in common which has an element for each module, the module's corresponding element is set when the module is ready to proceed.)

I was having issues with this 'rendezvous' mechanism, because one of the modules was dying and all the other tasks were waiting on it, without giving any indication, so I added a Text_IO.Put_Line() to print some debug information.

Text_IO.Put_Line( Proc_Enum'Image(thisPID)&" waiting for "& Proc_Enum'Image(waitPID));

Here is where the strange part happens:

One of the other modules has a large array of records (~85,000 records comprising ~5MB of data) that needs to be sorted. While the sort of the record array is happening, the other modules are waiting on this one. The other modules loop, checking for all of the rendezvous array entries to be set true, and keep printing the 'waiting for' message (once every 2 seconds for each module.)

So the strange part is, the Put_Line is not always printing the message being requested. Randomly it will print what appears to be parts of the records that are being sorted.

I believe that there is something wrong with the context switching between the threads. That the Put_Line() isn't thread safe, and that somehow, when the threads switch back to a module that is in the middle of printing the 'waiting for' text to the screen, that context memory isn't being reset properly.

Originally I thought that something was wrong with the existing legacy Sort code, and I replaced it with an Ada.Containers.Generic_Array_Sort implementation. While the sort appears to be quicker, the Put_Line() output is still corrupted - and the corruption is different with each subsequent run.

Sometimes the entire line of text is replaced, other times it is just a portion of the text.

For instance, the output should print something like:

PROCESS1 waiting for PROCESS9

I will see lines such as the following:

PRlanSS1 waiting for PROC9
element1

sometimes, since the Linux 'Terminal' program will display unprintable characters as boxes with the hex codes, I'll see some of those in the middle of the text string, ending a text string.

I figure random data from the records is occasionally being pulled into the buffer that Text_IO.Put_Line() is using to assemble the string before it writes it to the screen.

Unfortunately, I can not think of any way to track this down further.

I'm not sure if this is an Ada bug, a threading bug or a bug due to the architecture of this application.

While I could ignore the random printing, I am concerned that if the threads are not context switching properly, that any and all data structures in the application could be corrupted at any time during a thread switch...

So, one question I had was: Is Text_IO.Put_Line() known to be thread safe within GNAT.
Another is: Am I missing some sort of quick/obvious way to mark the Put_Line as a 'critical code' section that cannot be preempted?

I have been using Ada off and on for a few years, but I'm much more of a C guy than an Ada guy.

Thanks in advance for any suggestions you might be able to provide!

[Robert A Duff]

awdorrin <awdo...@gmail.com> writes:

> Text_IO.Put_Line( Proc_Enum'Image(thisPID)&" waiting for "& Proc_Enum'Image(waitPID));

Put_Line is not thread safe when called by multiple tasks
on the same file. The file here is standard output. Standard output
is a shared variable, so if you want to access it from multiple tasks,
you need to synchronize. For example, you could have a single
"debugging output" task, with a Put_Line entry, and call that
from multiple tasks. The Put_Line entry could call Text_IO.Put_Line
from within the rendezvous, or you could do some fancier buffering.

You can call Put_Line from multiple tasks without synchronization
if each task is writing to a different file.

There's a logging facility that's part of gnatcoll, but I have never
used it, and I don't know if it is thread safe.

It's a good idea to put an exception handler at the bottom of every
task body, and do some debugging output there. Otherwise, an
exception will cause the task to silently vanish. This is a
language design flaw.

- Bob

[Adam Beneschan]

On Thursday, June 14, 2012 6:49:45 AM UTC-7, Robert A Duff wrote:

> It's a good idea to put an exception handler at the bottom of every
> task body, and do some debugging output there. Otherwise, an
> exception will cause the task to silently vanish. This is a
> language design flaw.

Starting with Ada 2005, you can also use Ada.Task_Termination.Set_Dependents_Fallback_Handler in your main program. (See RM C.7.3.) Probably you should do both.

-- Adam

[Dmitry A. Kazakov]

On Thu, 14 Jun 2012 09:49:45 -0400, Robert A Duff wrote:

> It's a good idea to put an exception handler at the bottom of every
> task body, and do some debugging output there. Otherwise, an
> exception will cause the task to silently vanish. This is a
> language design flaw.

It would be nice if the exception would propagate in the task's master, but
that is impossible without a rendezvous or asynchronous control transfer on
the master's side.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[J-P. Rosen]

Le 14/06/2012 16:38, Dmitry A. Kazakov a �crit :

> It would be nice if the exception would propagate in the task's master, but
> that is impossible without a rendezvous or asynchronous control transfer on
> the master's side.
>

Asynchronous raising of exceptions was in preliminary Ada, the issue was
studied, and removed for Ada 83. It was proposed again for Ada95, fully
reassessed, and dismissed again. It was in Java1, and strongly
discouraged (nothing disappears from Java!) starting from Java2.

Definitely a bad idea!

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[awdorrin]

On Thursday, June 14, 2012 9:49:45 AM UTC-4, Robert A Duff wrote:

> awdorrin writes:
>
> > Text_IO.Put_Line( Proc_Enum'Image(thisPID)&" waiting for "& Proc_Enum'Image(waitPID));
>
> Put_Line is not thread safe when called by multiple tasks
> on the same file. The file here is standard output. Standard output
> is a shared variable, so if you want to access it from multiple tasks,
> you need to synchronize.

<snip>
>
> - Bob

I was afraid of that... I was hoping that there would be a way to set a flag to keep the task from switching in the middle of the Put_Line.

Something like:
CriticalSection.On;
Text_IO.Put_Line("blah blah");
CriticalSection.Off;

(Thinking back to Win32 C programming days...)

I'm not that worried about the corruption in the Put_Line itself, what I'm worried about is if the corruption will go both ways, meaning could it corrupt the record array that is being sorted. (Like the text string being printed ending up in the middle of a data record.)

[Dmitry A. Kazakov]

On Thu, 14 Jun 2012 16:56:16 +0200, J-P. Rosen wrote:

> Le 14/06/2012 16:38, Dmitry A. Kazakov a écrit :
>> It would be nice if the exception would propagate in the task's master, but
>> that is impossible without a rendezvous or asynchronous control transfer on
>> the master's side.
>>
> Asynchronous raising of exceptions was in preliminary Ada, the issue was
> studied, and removed for Ada 83. It was proposed again for Ada95, fully
> reassessed, and dismissed again. It was in Java1, and strongly
> discouraged (nothing disappears from Java!) starting from Java2.
>
> Definitely a bad idea!

Yes, I wonder why it was considered at all, it does not make any sense to
me.

I thought about exception propagating from any accept statement the master
would perform, unless the statement had an alternative of some reserved
name, which would take exception occurrence of the client as a parameter.

[Robert A Duff]

awdorrin <awdo...@gmail.com> writes:

> I was afraid of that... I was hoping that there would be a way to set
> a flag to keep the task from switching in the middle of the Put_Line.

It's not just an issue of task switching.
Consider a multiprocessor machine.

> Something like:
> CriticalSection.On;
> Text_IO.Put_Line("blah blah");
> CriticalSection.Off;

It's not hard to write a protected object CriticalSection
that does something like that. But you don't want to
scatter those calls all over -- you want a single atomic
Put_Line primitive.

> (Thinking back to Win32 C programming days...)
>
> I'm not that worried about the corruption in the Put_Line itself, what
> I'm worried about is if the corruption will go both ways, meaning
> could it corrupt the record array that is being sorted. (Like the text
> string being printed ending up in the middle of a data record.)

I'm not sure what you mean by that, but if you don't do proper
synchronization, it's erroneous, which means anything could
happen, including corruption of arbitrary data.

You might have other race conditions in your code (besides
the Put_Lines, I mean) -- something worth looking for.

- Bob

[Robert A Duff]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:

> It would be nice if the exception would propagate in the task's master, but
> that is impossible without a rendezvous or asynchronous control transfer on
> the master's side.

Probably the best default behavior would be to stop the program
with an error message, just like what happens for an unhandled
exception in the main program. If you don't like that, you would
program something else.

But as a default behavior, silently dropping exceptions on the
floor is a wrong language design.

- Bob

[Robert A Duff]

"J-P. Rosen" <ro...@adalog.fr> writes:

> Asynchronous raising of exceptions was in preliminary Ada, the issue was
> studied, and removed for Ada 83.

Not really. It was renamed to be "abort". The semantics of
"abort" in Ada 83 are essentially the same as the semantics
of T'Failure in preliminary Ada.

In all Ada implementations I have worked on (which is a lot),
abort is implemented internally via a special exception that
is invisible to user code.

In any case, it doesn't make sense for a single task to be
raising two exceptions at the same time, so that must be
prevented. Likewise simultaneously aborting and raising
an exception.

- Bob

[Jeffrey Carter]

On 06/14/2012 05:53 AM, awdorrin wrote:
>
> One module is called 'Common' and is a central 'shared memory' location. The
> other modules will call functions in Common to request chunks of memory in
> which to store data structures.
>
> As the modules initialize themselves, they call another routine in Common to
> wait until all tasks are ready (basically there is an array defined in common
> which has an element for each module, the module's corresponding element is
> set when the module is ready to proceed.)

This design sounds suspect to me. Everything in Common needs to be protected if
it's being accessed by multiple tasks.

> I was having issues with this 'rendezvous' mechanism, because one of the
> modules was dying and all the other tasks were waiting on it, without giving
> any indication, so I added a Text_IO.Put_Line() to print some debug
> information.
>
> Text_IO.Put_Line( Proc_Enum'Image(thisPID)&" waiting for"&
> Proc_Enum'Image(waitPID));

Is this in Common, or in the tasks that use Common?

--
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail
15

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[awdorrin]

On Thursday, June 14, 2012 2:24:49 PM UTC-4, Robert A Duff wrote:
> > I'm not that worried about the corruption in the Put_Line itself, what
> > I'm worried about is if the corruption will go both ways, meaning
> > could it corrupt the record array that is being sorted. (Like the text
> > string being printed ending up in the middle of a data record.)
>
> I'm not sure what you mean by that, but if you don't do proper
> synchronization, it's erroneous, which means anything could
> happen, including corruption of arbitrary data.

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.

I really cannot believe that the Put_Line's aren't thread safe.

[awdorrin]

On Thursday, June 14, 2012 2:56:05 PM UTC-4, Jeffrey Carter wrote:
> This design sounds suspect to me. Everything in Common needs to be protected if
> it's being accessed by multiple tasks.

The design is incredibly bad, in my opinion. This is 25 year old code, originally written in Ada83 for an AIX RISC system. The original application was multiple AIX processes. This code was then ported to VxWorks and the processes were made VxWorks tasks.

Now I've been given the task of porting the application from VxWorks to Linux. Considering it is nearly 300k SLOC of Ada and C (written for Big Endian RISC/Motorola) the port has been pretty successful so far.

> >
> > Text_IO.Put_Line( Proc_Enum'Image(thisPID)&" waiting for"&
> > Proc_Enum'Image(waitPID));
>
> Is this in Common, or in the tasks that use Common?
>

The procedure that contains the 'Rendezvous_With_Others' procedure is located in the common package, which is then 'With'd into every other thread. Common has both Ada and C interfaces to the same functions/procedures. One thread is the 'Control' thread, while the others wait for it, but they are all calling the Rendezvous_With_Others procedure, passing in their ID.

It is a mess, and if I could re-design the whole thing, I would. Unfortunately I'm being told 'make it work' and that since the application has been used for 25+ years on the other platforms that there isn't anything wrong with the design.

[tmo...@acm.org]

> > It's a good idea to put an exception handler at the bottom of every
> > task body, and do some debugging output there. Otherwise, an
> > exception will cause the task to silently vanish. This is a
> > language design flaw.
>
> It would be nice if the exception would propagate in the task's master,

Not quite the same, but possibly useful:

with Ada.Exceptions;
procedure Testte is
task type T is
entry A;
entry B(I : in Integer);
entry C;
end;
task body T is
Dummy : Natural := 1;
begin
accept A;
select
accept C;
or
delay 3.0;
end select;
Dummy := Dummy - 2; -- cause exception
exception
when Surprise: others =>
declare
use Ada.Exceptions;
Ea : Exception_Occurrence_Access := Save_Occurrence(Surprise);
begin
select
accept A do Reraise_Occurrence(Ea.all);end;
or
accept B(I : in Integer) do Reraise_Occurrence(Ea.all);end;
or
accept C do Reraise_Occurrence(Ea.all);end;
or
terminate; -- died and nobody noticed!
end select;
end;
end T;
This : T;
begin
This.A;
This.C; -- will cause This to have an internal, post-rendezvous, exception
This.A; -- The next call on This will get that saved exception
end Testte;

[Robert A Duff]

awdorrin <awdo...@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.

- Bob

[Robert A Duff]

awdorrin <awdo...@gmail.com> writes:

> It is a mess, and if I could re-design the whole thing, I
> would. Unfortunately I'm being told 'make it work' and that since the
> application has been used for 25+ years on the other platforms that
> there isn't anything wrong with the design.

Sounds painful. Perhaps you should try making the new system behave as
much like the old one as possible. For example, limit it to a single
processor (which was probably the case 25 years ago).

- Bob

[Jeffrey Carter]

On 06/14/2012 01:50 PM, awdorrin wrote:
>
> It is a mess, and if I could re-design the whole thing, I would.
> Unfortunately I'm being told 'make it work' and that since the application
> has been used for 25+ years on the other platforms that there isn't anything
> wrong with the design.

That hardly follows. People use badly designed things all the time. For decades
the standard design for plumbing was 2 separate faucets (hot and cold) each with
its own valve. That's a terrible design from a usability standpoint. Then came a
single faucet with separate valves for hot and cold. That's better, but
determining the valve positions for a desired combination of water temperature
and pressure is difficult. A much better design is a single faucet with
independent controls for temperature and pressure.

[Simon Wright]

Jeffrey Carter <spam.jrc...@spam.not.acm.org> writes:

> For decades the standard design for plumbing was 2 separate faucets
> (hot and cold) each with its own valve. That's a terrible design from
> a usability standpoint.

?

Personally I find it a highly usable design.

Perhaps it could be improved, by berating installers who connect the hot
tap on the right until they see the error of their ways.

[Jeffrey Carter]

On 06/14/2012 03:40 PM, Simon Wright wrote:
> Jeffrey Carter<spam.jrc...@spam.not.acm.org> writes:
>
>> For decades the standard design for plumbing was 2 separate faucets
>> (hot and cold) each with its own valve. That's a terrible design from
>> a usability standpoint.
>

> Personally I find it a highly usable design.

If all you ever do is fill a receptacle (sink/tub) with water, sure. But suppose
you want to wash your hands in water warmer than the water from the cold tap,
and cooler than the water from the hot tap, and rinse them in clean water of the
same temperature.

With 2 taps:

Plug sink
Turn on both taps
Mostly fill sink
Turn off both taps
Mix water in sink and test temperature
Add more water from one tap to obtain desired temperature
Wash hands
Drain sink
Plug sink
Turn on both taps (getting them soapy)
Mostly fill sink
Turn off both taps
Mix water in sink and test temperature
Add more water from one tap to obtain desired temperature
Rinse hands
Drain sink
Plug sink
Turn on both taps (getting your hands soapy)
Mostly fill sink
Turn off both taps
Mix water in sink and test temperature
Add more water from one tap to obtain desired temperature
Rinse hands and taps
Drain sink

With a single faucet and independent temperature and pressure controls:

Adjust pressure
Adjust temperature
Wash hands
Rinse hands
Turn off water

I find the latter much more usable. Of course, if you don't mind rinsing your
hands in dirty, soapy water (getting them dirty again, so why bother washing
them in the 1st place?), you can make the 2-tap scenario much shorter.

Of course, 2 separate taps are hopeless for showering ...

[Simon Wright]

Jeffrey Carter <spam.jrc...@spam.not.acm.org> writes:

> On 06/14/2012 03:40 PM, Simon Wright wrote:
>> Jeffrey Carter<spam.jrc...@spam.not.acm.org> writes:
>>
>>> For decades the standard design for plumbing was 2 separate faucets
>>> (hot and cold) each with its own valve. That's a terrible design from
>>> a usability standpoint.
>>
>> Personally I find it a highly usable design.
>
> If all you ever do is fill a receptacle (sink/tub) with water,
> sure. But suppose you want to wash your hands in water warmer than the
> water from the cold tap, and cooler than the water from the hot tap,
> and rinse them in clean water of the same temperature.
>
> With 2 taps:
>

[accurate description of process for washing hands if you need enough
water that you can't complete the process under just the hot tap without
scalding yourself]

>
> With a single faucet and independent temperature and pressure controls:
>
> Adjust pressure
> Adjust temperature

[swearing horribly because you can't work out how to use the unfamiliar
controls and getting the tap dirty so that you have to rinse it off
later]
> Wash hands
[swearing horribly because you manage to knock the unfamiliar controls
and scald yourself]

> Rinse hands
> Turn off water

> Of course, 2 separate taps are hopeless for showering ...

A different use case. Though, see above about horrible swearing.

[Georg Bauhaus]

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.

[Jeffrey Carter]

On 06/14/2012 10:04 PM, Simon Wright wrote:
>>
> [accurate description of process for washing hands if you need enough
> water that you can't complete the process under just the hot tap without
> scalding yourself]

In other words, not at a chosen temperature but at whatever the system gives
you. Not something I want to do.

>> With a single faucet and independent temperature and pressure controls:
>>
>> Adjust pressure
>> Adjust temperature
> [swearing horribly because you can't work out how to use the unfamiliar
> controls and getting the tap dirty so that you have to rinse it off
> later]
>> Wash hands
> [swearing horribly because you manage to knock the unfamiliar controls
> and scald yourself]
>> Rinse hands
>> Turn off water
>
>> Of course, 2 separate taps are hopeless for showering ...
>
> A different use case. Though, see above about horrible swearing.

Funny, but I've never done the horrible swearing, or had much difficulty
figuring out such controls.

[Dmitry A. Kazakov]

On Fri, 15 Jun 2012 07:32:14 +0200, Georg Bauhaus wrote:

> On 14.06.12 23:37, Robert A Duff wrote:
>> 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 lower-level I/O yes.

The higher-level I/O should be transaction-oriented in order to be
task-safe.

I disagree with Robert: 1) Transactions would be difficult to do taking
into account language problems with MI and MD; 2) I don't consider Text_IO
design wrong.

[awdorrin]

On Thursday, June 14, 2012 5:41:42 PM UTC-4, Robert A Duff wrote:

> awdorrin writes:
>
> Sounds painful. Perhaps you should try making the new system behave as
> much like the old one as possible. For example, limit it to a single
> processor (which was probably the case 25 years ago).
>
> - Bob

It has been quite challenging, interesting at times and incredibly frustrating at others.

I am currently binding the application to one CPU core, with a call to sched_setaffinity(). Or at least I thought I was... I'll have to verify that the setting is propagating to every thread... Thanks!

[Robert A Duff]

Georg Bauhaus <rm.dash...@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

[Robert A Duff]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:

> The lower-level I/O yes.
>
> The higher-level I/O should be transaction-oriented in order to be
> task-safe.

Agreed.

> I disagree with Robert:

Sounded above like you were agreeing. ;-)

1) Transactions would be difficult to do taking
> into account language problems with MI and MD;

I don't understand that part.

2) I don't consider Text_IO
> design wrong.

With respect to task safety, or in general?

- Bob

[BrianG]

On 06/14/2012 06:17 PM, Jeffrey Carter wrote:
> On 06/14/2012 01:50 PM, awdorrin wrote:
>>
>> It is a mess, and if I could re-design the whole thing, I would.
>> Unfortunately I'm being told 'make it work' and that since the
>> application
>> has been used for 25+ years on the other platforms that there isn't
>> anything
>> wrong with the design.
>
> That hardly follows. People use badly designed things all the time. For
> decades the standard design for plumbing was 2 separate faucets (hot and
> cold) each with its own valve. That's a terrible design from a usability
> standpoint. Then came a single faucet with separate valves for hot and
> cold. That's better, but determining the valve positions for a desired
> combination of water temperature and pressure is difficult. A much
> better design is a single faucet with independent controls for
> temperature and pressure.
>

Sounds like that was part of the direction given, not a choice made (by
the recipient of the direction). You can't necessarily expect sense in
what you're told to do.

On the Put_Line issue, why not simply wrap it in a protected object, and
change Ada.Text_IO ref's to that object? That won't help with the
sequence-of-calls issues; you'd need individual protected calls for each
sequence.

--
---
BrianG
000
@[Google's email domain]
.com

[J-P. Rosen]

Le 16/06/2012 04:00, BrianG a écrit :
> On the Put_Line issue, why not simply wrap it in a protected object

Because all IO's are potentially blocking operations.

By all means, use a task and a rendezvous! Simple, no problem, it works.
PO are for simple, relatively low level stuff (in general). Rendezvous
are generally better for high level synchronization.

[Simon Wright]

"J-P. Rosen" <ro...@adalog.fr> writes:

> Le 16/06/2012 04:00, BrianG a écrit :
>> On the Put_Line issue, why not simply wrap it in a protected object
> Because all IO's are potentially blocking operations.
>
> By all means, use a task and a rendezvous! Simple, no problem, it works.
> PO are for simple, relatively low level stuff (in general). Rendezvous
> are generally better for high level synchronization.

I feel more comfortable it the output requests are queued, so a PO
wrapping a queue with an outputter task seems natural.

Or, nowadays, a synchronized queue (but note, that's for definite types
only, not so good for strings).

[Dmitry A. Kazakov]

On Fri, 15 Jun 2012 17:32:43 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>
>> 1) Transactions would be difficult to do taking
>> into account language problems with MI and MD;
>
> I don't understand that part.

File I/O was done in an non-OO way. It was OK for Ada 83. File I/O was
expected unsafe, there was only ASCII, life was simpler in 80's (:-)).
Transaction level should be added for safety. I don't want even to imagine
it designed as a bunch of unsorted procedures cut'n'pasted for all possible
combinations of files, items, streams, encodings, I/O modes.

>> 2) I don't consider Text_IO
>> design wrong.
>
> With respect to task safety, or in general?

Tasking.

[Dmitry A. Kazakov]

On Sat, 16 Jun 2012 08:04:47 +0200, J-P. Rosen wrote:

> Le 16/06/2012 04:00, BrianG a écrit :
>> On the Put_Line issue, why not simply wrap it in a protected object
> Because all IO's are potentially blocking operations.

And even if they would not be, one should keep protected actions as short
as possible.

> By all means, use a task and a rendezvous!

An alternative is a reentrant mutex seized and released by a controlled
holder object.

> Simple, no problem, it works.
> PO are for simple, relatively low level stuff (in general). Rendezvous
> are generally better for high level synchronization.

Yes, but also significantly slower. Usually some combination of both is the
best solution.

[Dmitry A. Kazakov]

On Sat, 16 Jun 2012 07:49:26 +0100, Simon Wright wrote:

> "J-P. Rosen" <ro...@adalog.fr> writes:
>
>> Le 16/06/2012 04:00, BrianG a écrit :
>>> On the Put_Line issue, why not simply wrap it in a protected object
>> Because all IO's are potentially blocking operations.
>>
>> By all means, use a task and a rendezvous! Simple, no problem, it works.
>> PO are for simple, relatively low level stuff (in general). Rendezvous
>> are generally better for high level synchronization.
>
> I feel more comfortable it the output requests are queued, so a PO
> wrapping a queue with an outputter task seems natural.

That would need marshaling. Rendezvous and mutexes are great because they
copy nothing.

IMO, queues should only be used for asynchronous scenarios.

[Simon Wright]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:

> On Sat, 16 Jun 2012 07:49:26 +0100, Simon Wright wrote:
>
>> "J-P. Rosen" <ro...@adalog.fr> writes:
>>
>>> Le 16/06/2012 04:00, BrianG a écrit :
>>>> On the Put_Line issue, why not simply wrap it in a protected object
>>> Because all IO's are potentially blocking operations.
>>>
>>> By all means, use a task and a rendezvous! Simple, no problem, it
>>> works. PO are for simple, relatively low level stuff (in
>>> general). Rendezvous are generally better for high level
>>> synchronization.
>>
>> I feel more comfortable it the output requests are queued, so a PO
>> wrapping a queue with an outputter task seems natural.
>
> That would need marshaling. Rendezvous and mutexes are great because
> they copy nothing.

So? this is usually for debug.

> IMO, queues should only be used for asynchronous scenarios.

In my scenario, getting the log information out is lower-priority than
handling the real-time processing. You May Not Block while processing
events.

[Dmitry A. Kazakov]

On Sat, 16 Jun 2012 09:03:08 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>
>> On Sat, 16 Jun 2012 07:49:26 +0100, Simon Wright wrote:
>>
>>> "J-P. Rosen" <ro...@adalog.fr> writes:
>>>
>>>> Le 16/06/2012 04:00, BrianG a écrit :
>>>>> On the Put_Line issue, why not simply wrap it in a protected object
>>>> Because all IO's are potentially blocking operations.
>>>>
>>>> By all means, use a task and a rendezvous! Simple, no problem, it
>>>> works. PO are for simple, relatively low level stuff (in
>>>> general). Rendezvous are generally better for high level
>>>> synchronization.
>>>
>>> I feel more comfortable it the output requests are queued, so a PO
>>> wrapping a queue with an outputter task seems natural.
>>
>> That would need marshaling. Rendezvous and mutexes are great because
>> they copy nothing.
>
> So? this is usually for debug.

When debugging you should not pump the stack and heap too much. You also
would not like to keep it in the volatile memory for too long, because the
thing might crash before that reaches the hard drive or monitor.

>> IMO, queues should only be used for asynchronous scenarios.
>
> In my scenario, getting the log information out is lower-priority than
> handling the real-time processing. You May Not Block while processing
> events.

Yes, RT is one case where one wanted to convert a synchronous operation
into an asynchronous one. But that is a design decision motivated by more
than mere task-safety reasons.

[Randy Brukardt]

"Robert A Duff" <bob...@shell01.TheWorld.com> wrote in message
news:wccy5np...@shell01.TheWorld.com...

> "J-P. Rosen" <ro...@adalog.fr> writes:
>
>> Asynchronous raising of exceptions was in preliminary Ada, the issue was
>> studied, and removed for Ada 83.
>
> Not really. It was renamed to be "abort". The semantics of
> "abort" in Ada 83 are essentially the same as the semantics
> of T'Failure in preliminary Ada.
>
> In all Ada implementations I have worked on (which is a lot),
> abort is implemented internally via a special exception that
> is invisible to user code.

Really? No wonder we spent so much time on "abort"! :-)

There are no exceptions in our tasking implementation. There is a special
entry that takes an exception_occurrence that gets called in the exception
handler of a rendezvous (and all rendezvous have such a handler for all
exception, added by the compiler if necessary); that's used to generate the
needed replication of the exception. Abort is handled by a lot of code
implementing the "abnormal" state; some of it shares the mechanism for
finalizating a task upon completion.

I don't know what happens if an exception is raised in the "abnormal" state,
I wouldn't expect it to be special.

Randy.

[Randy Brukardt]

"Robert A Duff" <bob...@shell01.TheWorld.com> wrote in message

news:wcc395x...@shell01.TheWorld.com...

> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>

>> It would be nice if the exception would propagate in the task's master,

>> but
>> that is impossible without a rendezvous or asynchronous control transfer
>> on
>> the master's side.
>
> Probably the best default behavior would be to stop the program
> with an error message, just like what happens for an unhandled
> exception in the main program. If you don't like that, you would
> program something else.

Wouldn't that be really expensive on a multicore processor (or, in Ada 83
think, a multiprocessor)? Maybe it could be defined in terms of "abort", but
that seems like a heavy mechanism.

> But as a default behavior, silently dropping exceptions on the
> floor is a wrong language design.

I agree. The problem is everything else is worse in some way. ;-)

Randy.

[Randy Brukardt]

"Simon Wright" <si...@pushface.org> wrote in message
news:m2aa05j...@pushface.org...
> Jeffrey Carter <spam.jrc...@spam.not.acm.org> writes:
...

>> With a single faucet and independent temperature and pressure controls:

Ah, like the hotel in Stockholm. But you don't have this quite right.

>> Adjust pressure

Hollering because the water starts off cold and then slowly warms up...

>> Adjust temperature

And discover that it doesn't matter because no matter what you set it to, it
immediately (but slowly) rotates back to fully hot. (Luckily, this being
Europe, it wasn't hot enough to get scalded. The result would be different
at home.)

...
At least most such faucets that I've used in here in the States aren't
really independent -- they're pull for on or off (adjusting the pressure
with any granularity is nearly impossible), and turn for temperature. Hotel
faucets can be a real struggle, however, because they're so worried about
someone getting scalded (and then suing them for $$$$) that they default to
frigid and make it hard to get anything warm (especially annoying in the
shower).

Randy.

[Randy Brukardt]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:17b8mcqy4f63k$.1jwvmc6qjjvnq$.dlg@40tude.net...
...

> IMO, queues should only be used for asynchronous scenarios.

You're right, but shared I/O is (almost) always asynchronous. That is, queue
up a debug log entry, output it whenever, but don't block the caller for a
log entry (you still have to process incoming mail/web requests/whatever no
matter how clogged the logger is).

Synchronous shared I/O shouldn't be mixed with tasks, because it completely
defeats the purpose of using tasks in the first place. The I/O serializes
the tasks, and you now just have a very complex sequential program; you
might as well have written a simple sequential program without the tasks. I
generally use one task per I/O channel if the purpose of the task involves
I/O, then no extra task safety is required (and, as noted, logging is
asynchronous).

Randy.