* Re: Tasking differences [not found] ` <396AECA4.30B03835@baesystems.com> @ 2000-07-12 0:00 ` Robert Dewar 2000-07-12 0:00 ` Martin Dowie 0 siblings, 1 reply; 9+ messages in thread From: Robert Dewar @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Tasking differences 2000-07-12 0:00 ` Tasking differences Robert Dewar @ 2000-07-12 0:00 ` Martin Dowie 0 siblings, 0 replies; 9+ messages in thread From: Martin Dowie @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <uk8etc788.fsf@baesystems.com>]
[parent not found: <8kff0n$nnu$1@nnrp1.deja.com>]
* Re: Tasking differences [not found] ` <8kff0n$nnu$1@nnrp1.deja.com> @ 2000-07-12 0:00 ` Robert Dewar 2000-07-12 0:00 ` Larry Kilgallen 2000-07-12 0:00 ` Ted Dennison 0 siblings, 2 replies; 9+ messages in thread From: Robert Dewar @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Tasking differences 2000-07-12 0:00 ` Robert Dewar @ 2000-07-12 0:00 ` Larry Kilgallen 2000-07-12 0:00 ` Robert Dewar 2000-07-12 0:00 ` Ted Dennison 1 sibling, 1 reply; 9+ messages in thread From: Larry Kilgallen @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Tasking differences 2000-07-12 0:00 ` Larry Kilgallen @ 2000-07-12 0:00 ` Robert Dewar 2000-07-13 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 9+ messages in thread From: Robert Dewar @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Tasking differences 2000-07-12 0:00 ` Robert Dewar @ 2000-07-13 0:00 ` Larry Kilgallen 2000-07-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 9+ messages in thread From: Larry Kilgallen @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Tasking differences 2000-07-13 0:00 ` Larry Kilgallen @ 2000-07-13 0:00 ` Robert Dewar 0 siblings, 0 replies; 9+ messages in thread From: Robert Dewar @ 2000-07-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Tasking differences 2000-07-12 0:00 ` Robert Dewar 2000-07-12 0:00 ` Larry Kilgallen @ 2000-07-12 0:00 ` Ted Dennison 2000-07-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 9+ messages in thread From: Ted Dennison @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Tasking differences 2000-07-12 0:00 ` Ted Dennison @ 2000-07-12 0:00 ` Robert Dewar 0 siblings, 0 replies; 9+ messages in thread From: Robert Dewar @ 2000-07-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-07-13 0:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3969B65A.46942054@baesystems.com> [not found] ` <8ke8ao$rs3$1@nnrp1.deja.com> [not found] ` <396AECA4.30B03835@baesystems.com> 2000-07-12 0:00 ` Tasking differences Robert Dewar 2000-07-12 0:00 ` Martin Dowie [not found] ` <uk8etc788.fsf@baesystems.com> [not found] ` <8kff0n$nnu$1@nnrp1.deja.com> 2000-07-12 0:00 ` Robert Dewar 2000-07-12 0:00 ` Larry Kilgallen 2000-07-12 0:00 ` Robert Dewar 2000-07-13 0:00 ` Larry Kilgallen 2000-07-13 0:00 ` Robert Dewar 2000-07-12 0:00 ` Ted Dennison 2000-07-12 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox