Re: Tasking differences

Re: Tasking differences

[Robert Dewar]

In article <396AECA4.30B03835@baesystems.com>,
  Martin Dowie <martin.dowie@baesystems.com> wrote:
> sorry, but I can't see why there should be any difference in
*results* of the
> two - if they were so different, why does GNAT produce the
same results for both
> versions? I understand that the scheduling of the 2 tasks can
change given the
> differences, but in this case I don't see why that should
affect the outcome.

Running code locked instead of unlocked makes a big difference
in the set of possible outcomes, the fact that with one
particular scheduling discipline you see no differences proves
nothing about the possible non-deterministic set of outcomes!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Tasking differences

[Robert Dewar]

In article <8kff0n$nnu$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Hmm. That makes perfect sense, and would fully explain the
> behavior. Most Ada runtimes have a little problem where
> Ada.Text_IO is not thread-safe.

That's misleading. Ada.Text_IO is required to be thread safe,
and it would be surprising if it were not the case. Probably
what you are referring to is having two tasks use Ada.Text_IO
*on the same file* without any protection, but that's clearly
an unsychronized use of a shared variable, so the program is
erroneous. The "little problem" is in the client!

> It would be fairly easy to make it thread-safe by
> creating a task or protected object to synchornize accesses to
> it. I've often wondered why more vendors didn't do that.

Because

  a) there is no requirement in the RM to do this
  b) the programs you are talking about are erroneous
  c) this kind of locking is expensive

Certainly if the problem is that you have multiple tasks doing
Put to the same file without synchronization, then absolutely
anything may happen when you run the program!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Tasking differences

[Martin Dowie]

i should have been clearer - yes the output is non-deterministic, but the
outcome that wasn't 'expected' was that it hangs when attempting a second
'select ... else' - the non-deterministic output was entirely expected!

on removal of timer variables, pragma priorities and most text_io, except from
the 'stop' subprogram that is called by the main program, we still see the same
'hanging'/'non-hanging' differences.

the best guess so far is that there is a bug in the behaviour of 'select ...
else' statements and delays (thanks pete).

Robert Dewar wrote:
> 
> In article <396AECA4.30B03835@baesystems.com>,
>   Martin Dowie <martin.dowie@baesystems.com> wrote:
> > sorry, but I can't see why there should be any difference in
> *results* of the
> > two - if they were so different, why does GNAT produce the
> same results for both
> > versions? I understand that the scheduling of the 2 tasks can
> change given the
> > differences, but in this case I don't see why that should
> affect the outcome.
> 
> Running code locked instead of unlocked makes a big difference
> in the set of possible outcomes, the fact that with one
> particular scheduling discipline you see no differences proves
> nothing about the possible non-deterministic set of outcomes!
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
The views expressed here are personnal and not those of BAE Systems.

Re: Tasking differences

[Larry Kilgallen]

In article <8kgkdp$kjv$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:

> Certainly if the problem is that you have multiple tasks doing
> Put to the same file without synchronization, then absolutely
> anything may happen when you run the program!

But for some given compiler/OS, it might be perfectly orderly
for situations like log files where the order of the records is
not of concern.

Re: Tasking differences

[Ted Dennison]

In article <8kgkdp$kjv$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8kff0n$nnu$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
>
> > Hmm. That makes perfect sense, and would fully explain the
> > behavior. Most Ada runtimes have a little problem where
> > Ada.Text_IO is not thread-safe.
>
> That's misleading. Ada.Text_IO is required to be thread safe,
> and it would be surprising if it were not the case. Probably
> what you are referring to is having two tasks use Ada.Text_IO
> *on the same file* without any protection, but that's clearly

Well, yes. I was actually referring to the particular call he was
making, which was a use of Ada.Text_IO.Put_Line (the version that does
*not* take a file as a parameter). It should have been clear from the
context, but out of context I'll admit its a misleading statement.
Sorry.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Tasking differences

[Robert Dewar]

In article <sWAj2hU9Vh4n@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> In article <8kgkdp$kjv$1@nnrp1.deja.com>, Robert Dewar
<robert_dewar@my-deja.com> writes:
>
> > Certainly if the problem is that you have multiple tasks
doing
> > Put to the same file without synchronization, then
absolutely
> > anything may happen when you run the program!
>
> But for some given compiler/OS, it might be perfectly orderly
> for situations like log files where the order of the records
> is not of concern.

The problem is FAR worse than arbitrary interleaving. You are
doing uncoordinated writes to a variable (the internal file
variable), so the program is erroneous. Arbitrary interleaving
is actually a very nice behavior, but a program crash due to
inconsistent data structures is not unexpected in this situation
(or at least should NOT be unexpected). If you want this kind
of interleaving, you need to provide a synchronizing agent


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Tasking differences

[Robert Dewar]

In article <8ki4dg$m70$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> In article <8kgkdp$kjv$1@nnrp1.deja.com>,


> Well, yes. I was actually referring to the particular call he
was
> making, which was a use of Ada.Text_IO.Put_Line (the version
that does
> *not* take a file as a parameter). It should have been clear
from the
> context, but out of context I'll admit its a misleading
statement.
> Sorry.


Well my observation applies to this version as well, if two
tasks do

  Put_Line("...");

without any sychronization, and the two Put_Line calls are
executed at the same time, then the program execution is
erroneous, and anything can happen.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Tasking differences

[Larry Kilgallen]

In article <8kihp8$1cp$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <sWAj2hU9Vh4n@eisner.decus.org>,
>   Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
>> In article <8kgkdp$kjv$1@nnrp1.deja.com>, Robert Dewar
> <robert_dewar@my-deja.com> writes:
>>
>> > Certainly if the problem is that you have multiple tasks
> doing
>> > Put to the same file without synchronization, then
> absolutely
>> > anything may happen when you run the program!
>>
>> But for some given compiler/OS, it might be perfectly orderly
>> for situations like log files where the order of the records
>> is not of concern.
> 
> The problem is FAR worse than arbitrary interleaving. You are
> doing uncoordinated writes to a variable (the internal file
> variable), so the program is erroneous. Arbitrary interleaving
> is actually a very nice behavior, but a program crash due to
> inconsistent data structures is not unexpected in this situation
> (or at least should NOT be unexpected). If you want this kind
> of interleaving, you need to provide a synchronizing agent

Or ensure your tools provide it.  The DEC Ada Runtime Library is
on the VMS Listings kit.  There are calls to lock and unlock file
variables made during file operations.  Whether those calls are
perfect is certainly less tested than whether 1 + 1 = 2.

Re: Tasking differences

[Robert Dewar]

In article <n3ZhsJT3sddL@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:

> Or ensure your tools provide it.  The DEC Ada Runtime Library
> is on the VMS Listings kit.  There are calls to lock and
> unlock file variables made during file operations.  Whether
> those calls are perfect is certainly less tested than whether
> 1 + 1 = 2.

I disagree with this advice. Yes, you can often get away with
erroneous programs because they do the "right thing". But even
in a case like this where you "know" your compiler does the
right thing, you are casually creating highly non-portable
incorrect Ada code. A lot of trouble in porting to Ada 95 turns
out to be this kind of problem coding.


Sent via Deja.com http://www.deja.com/
Before you buy.