* Task_Barriers @ 2019-07-25 16:32 Gilbert Gosseyn 2019-07-25 16:43 ` Task_Barriers Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Gilbert Gosseyn @ 2019-07-25 16:32 UTC (permalink / raw) with Ada.Text_IO , Ada.Synchronous_Barriers ; use Ada.Text_IO , Ada.Synchronous_Barriers ; procedure Task_Barriers is NT: constant := 2; SB: Ada.Synchronous_Barriers.Synchronous_Barrier(NT) ; Notified : Boolean:= False ; task T1 ; task T2 ; X: Integer :=0; Y: Integer :=1; task body T1 is begin loop delay 1.0 ; Wait_For_Release (SB,Notified) ; X:=X+1; end loop ; end T1 ; task body T2 is begin loop delay 1.0 ; Wait_For_Release (SB, Notified) ; Y:=Y+1; end loop ; end T2 ; begin null ; end Task_Barriers ; This program runs forever, although it should stop when reaching an internal count number? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-25 16:32 Task_Barriers Gilbert Gosseyn @ 2019-07-25 16:43 ` Dmitry A. Kazakov 2019-07-25 18:56 ` Task_Barriers Dennis Lee Bieber 2019-07-25 20:17 ` Task_Barriers Simon Wright 2 siblings, 0 replies; 12+ messages in thread From: Dmitry A. Kazakov @ 2019-07-25 16:43 UTC (permalink / raw) On 2019-07-25 18:32, Gilbert Gosseyn wrote: > with Ada.Text_IO , Ada.Synchronous_Barriers ; > use Ada.Text_IO , Ada.Synchronous_Barriers ; > > procedure Task_Barriers is > NT: constant := 2; > SB: Ada.Synchronous_Barriers.Synchronous_Barrier(NT) ; > Notified : Boolean:= False ; > task T1 ; > task T2 ; > > X: Integer :=0; > Y: Integer :=1; > > task body T1 is > begin > loop > delay 1.0 ; > Wait_For_Release (SB,Notified) ; > X:=X+1; > end loop ; > end T1 ; > > task body T2 is > begin > loop > delay 1.0 ; > Wait_For_Release (SB, Notified) ; > Y:=Y+1; > end loop ; > end T2 ; > begin > null ; > end Task_Barriers ; > > This program runs forever, although it should stop when reaching an internal count number? From the description the barrier rearms itself again after releasing all tasks D.10.1 (11/3). So, it looks correct behavior to me. Both tasks get synchronized at the barrier and then repeat it again each second. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-25 16:32 Task_Barriers Gilbert Gosseyn 2019-07-25 16:43 ` Task_Barriers Dmitry A. Kazakov @ 2019-07-25 18:56 ` Dennis Lee Bieber 2019-07-25 20:11 ` Task_Barriers Jeffrey R. Carter 2019-07-25 20:17 ` Task_Barriers Simon Wright 2 siblings, 1 reply; 12+ messages in thread From: Dennis Lee Bieber @ 2019-07-25 18:56 UTC (permalink / raw) On Thu, 25 Jul 2019 09:32:15 -0700 (PDT), Gilbert Gosseyn <hnptz@yahoo.de> declaimed the following: > task body T2 is > begin > loop > delay 1.0 ; > Wait_For_Release (SB, Notified) ; > Y:=Y+1; > end loop ; > end T2 ; >begin > null ; >end Task_Barriers ; > >This program runs forever, although it should stop when reaching an internal count number? How did you determine "forever"? Ignoring the synchronization part, the loops have a one second delay per cycle, and you are incrementing an integer. Presuming integer is 32 bits, that means a loop that will take >>> 0x7FFFFFFF 2147483647 >>> seconds to complete. According to my HP-48sx, 2147483647_s -> 68.0511038598_yr (assuming integers generate overflow exceptions, your program will complete sometime in 2087) The description of Wait_For_Release() http://www.ada-auth.org/standards/12rat/html/Rat12-1-3-4.html has me wondering what purpose it really serves. "All the tasks are then released and just one of them is told about it by the parameter Notified being True. The general idea is that this one task then does something on behalf of all the others." So there is no determinism as to which task gets the True flag; that means any one of the waiting tasks could be responsible for doing this common activity, while the other tasks are doing what? -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-25 18:56 ` Task_Barriers Dennis Lee Bieber @ 2019-07-25 20:11 ` Jeffrey R. Carter 0 siblings, 0 replies; 12+ messages in thread From: Jeffrey R. Carter @ 2019-07-25 20:11 UTC (permalink / raw) On 7/25/19 8:56 PM, Dennis Lee Bieber wrote: > > Ignoring the synchronization part, the loops have a one second delay > per cycle, and you are incrementing an integer. > > Presuming integer is 32 bits, that means a loop that will take > >>>> 0x7FFFFFFF > 2147483647 >>>> > > seconds to complete. According to my HP-48sx, 2147483647_s -> > 68.0511038598_yr (assuming integers generate overflow exceptions, your > program will complete sometime in 2087) No, T2 will complete then. T1, and so the whole program, will then be blocked indefinitely, IIUC the semantics of the Synchronous_Barrier. -- Jeff Carter "I've seen projects fail miserably for blindly applying the Agile catechism: we're Agile, we don't need to stop and think, we just go ahead and code!" Bertrand Meyer 150 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-25 16:32 Task_Barriers Gilbert Gosseyn 2019-07-25 16:43 ` Task_Barriers Dmitry A. Kazakov 2019-07-25 18:56 ` Task_Barriers Dennis Lee Bieber @ 2019-07-25 20:17 ` Simon Wright 2019-07-25 21:59 ` Task_Barriers Randy Brukardt 2019-07-26 10:38 ` Task_Barriers Gilbert Gosseyn 2 siblings, 2 replies; 12+ messages in thread From: Simon Wright @ 2019-07-25 20:17 UTC (permalink / raw) Gilbert Gosseyn <hnptz@yahoo.de> writes: > although it should stop when reaching an internal count number What internal count number is that? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-25 20:17 ` Task_Barriers Simon Wright @ 2019-07-25 21:59 ` Randy Brukardt 2019-07-26 7:52 ` Task_Barriers Simon Wright 2019-07-26 10:38 ` Task_Barriers Gilbert Gosseyn 1 sibling, 1 reply; 12+ messages in thread From: Randy Brukardt @ 2019-07-25 21:59 UTC (permalink / raw) There's nothing in the definition of either task that would cause it to exit, regardless of what the barrier does, so the only result could possibly be to run more-or-less forever. (As noted by someone else, the loops run too slowly for overflow to happen on the counter, and there is no exit.) Randy. "Simon Wright" <simon@pushface.org> wrote in message news:lyv9vpamxi.fsf@pushface.org... > Gilbert Gosseyn <hnptz@yahoo.de> writes: > >> although it should stop when reaching an internal count number > > What internal count number is that? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-25 21:59 ` Task_Barriers Randy Brukardt @ 2019-07-26 7:52 ` Simon Wright 2019-07-26 23:59 ` Task_Barriers Dennis Lee Bieber 0 siblings, 1 reply; 12+ messages in thread From: Simon Wright @ 2019-07-26 7:52 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > There's nothing in the definition of either task that would cause it > to exit, regardless of what the barrier does, so the only result could > possibly be to run more-or-less forever. (As noted by someone else, > the loops run too slowly for overflow to happen on the counter, and > there is no exit.) Yes, but ... > "Simon Wright" <simon@pushface.org> wrote in message > news:lyv9vpamxi.fsf@pushface.org... >> Gilbert Gosseyn <hnptz@yahoo.de> writes: >> >>> although it should stop when reaching an internal count number >> >> What internal count number is that? ... my (somewhat over-Socratic) point was, "you (OP) talk about an 'internal count number' but your code has no such thing, I think you may be showing us a different version of your code from that which actually has the problem". ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-26 7:52 ` Task_Barriers Simon Wright @ 2019-07-26 23:59 ` Dennis Lee Bieber 0 siblings, 0 replies; 12+ messages in thread From: Dennis Lee Bieber @ 2019-07-26 23:59 UTC (permalink / raw) On Fri, 26 Jul 2019 08:52:13 +0100, Simon Wright <simon@pushface.org> declaimed the following: >... my (somewhat over-Socratic) point was, "you (OP) talk about an >'internal count number' but your code has no such thing, I think you may >be showing us a different version of your code from that which actually >has the problem". I suspect the OP was considering the discriminant on the barrier (2 tasks before release) as the counter. But as I read the documentation, once the /n/ tasks are released, the barrier counter goes back to 0 and the next cycle of the loops will resynchronize on the barrier. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-25 20:17 ` Task_Barriers Simon Wright 2019-07-25 21:59 ` Task_Barriers Randy Brukardt @ 2019-07-26 10:38 ` Gilbert Gosseyn 2019-07-26 11:09 ` Task_Barriers Dmitry A. Kazakov ` (2 more replies) 1 sibling, 3 replies; 12+ messages in thread From: Gilbert Gosseyn @ 2019-07-26 10:38 UTC (permalink / raw) On Thursday, July 25, 2019 at 10:17:47 PM UTC+2, Simon Wright wrote: > > > although it should stop when reaching an internal count number > > What internal count number is that? 1 with Ada . Text IO , Ada . Synchronous_Barriers ; 2 use Ada . Text IO , Ada . Synchronous_Barriers ; 4 procedure Task_Barriers is 5 NT: constant :=2; 6 SB: Ada.Synchronous_Barriers.Synchronous_Barrier (NT) ; 7 Notified : Boolean:= False ; 8 task T1 ; 9 task T2 ; 10 11 X: I n t e g e r :=0; 12 Y: I n t e g e r :=1; 13 14 task body T1 is 15 begin 16 loop 17 delay 1.0 ; 18 Wait_For_Release (SB, Notified ) ; 19 X:=X+1; 20 end loop ; 21 end T1 ; 22 23 task body T2 i s 24 begin 25 loop 26 delay 1.0 ; 27 Wait_For_Release (SB, Notified ) ; 28 Y:=Y+1; 29 end loop ; 30 end T2 ; 31 begin 32 nul l ; 33 end Task_Ba r r i e r s ; In this Task Barriers, procedure Task_Barriers is the parent of task T1 and task T2. There are two synchronization channels about between two tasks. Line 18 is sending a message that is meaning the number of blocked tasks associated with the Synchronous Barrier object is equal to the threshold, to the line 28 that is receiving this message and the statement is starting to execute. Here, the threshold is set to 2. In the same way, Line 27 is labeled with sending the message that the blocked tasks are released, while Line 19 is receiving it and starting to execute. Ada 2012 provides a language-de\ffined package to synchronously release a group of tasks after the number of blocked tasks reaches a specifi\fed count value. Each call to Wait_For_Release blocks the calling task until the number of blocked tasks associated with the Synchronous_Barrier object is equal to Release_Threshold, at which time all blocked tasks are released. Barrier_release waiting is that tasks calling Wait_For_Release are blocked by other possible tasks calling it until the number of blocked tasks associated with the Synchronous Barrier object is equal to threshold. Therefore it should stop. What may be wrong in my line of thinking? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-26 10:38 ` Task_Barriers Gilbert Gosseyn @ 2019-07-26 11:09 ` Dmitry A. Kazakov 2019-07-26 15:03 ` Task_Barriers Simon Wright 2019-07-27 0:10 ` Task_Barriers Dennis Lee Bieber 2 siblings, 0 replies; 12+ messages in thread From: Dmitry A. Kazakov @ 2019-07-26 11:09 UTC (permalink / raw) On 2019-07-26 12:38, Gilbert Gosseyn wrote: > Ada 2012 provides a language-de\ffined package to synchronously release a group of tasks after the number of blocked tasks reaches a specifi\fed count value. [...] > What may be wrong in my line of thinking? It is not a mechanism suitable for 1-n publisher-subscriber or multi-cast services (you were talking about messaging). Think of various scenarios when some of consumer/producer tasks die or get blocked. Semaphore is a too low-level primitive and with k>1 has almost no practical use. [See Ada protected objects] Otherwise, your code works as expected. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-26 10:38 ` Task_Barriers Gilbert Gosseyn 2019-07-26 11:09 ` Task_Barriers Dmitry A. Kazakov @ 2019-07-26 15:03 ` Simon Wright 2019-07-27 0:10 ` Task_Barriers Dennis Lee Bieber 2 siblings, 0 replies; 12+ messages in thread From: Simon Wright @ 2019-07-26 15:03 UTC (permalink / raw) Gilbert Gosseyn <hnptz@yahoo.de> writes: > Ada 2012 provides a language-defined package to synchronously release > a group of tasks after the number of blocked tasks reaches a specified > count value. Each call to Wait_For_Release blocks the calling task > until the number of blocked tasks associated with the > Synchronous_Barrier object is equal to Release_Threshold, at which > time all blocked tasks are released. Barrier_release waiting is that > tasks calling Wait_For_Release are blocked by other possible tasks > calling it until the number of blocked tasks associated with the > Synchronous Barrier object is equal to threshold. Therefore it should > stop. I see what you mean by the count value, but I don't understand what "it" it is that you think "should stop". The main program won't finish until both tasks have finished. Look at T1, for example: task body T1 is begin loop delay 1.0 ; Wait_For_Release (SB,Notified) ; X:=X+1; end loop ; end T1 ; when the number of tasks waiting on NT reaches 2, both the waiting tasks are released, and Notified is set True for the one that the runtime chooses (by the way, I think Notified should be a local variable here). So T1 wakes up, increments X, *and goes round the loop again*. Try putting in some trace statements: task body T1 is begin loop delay 1.0 ; Wait_For_Release (SB,Notified) ; X:=X+1; Put_Line ("t1 released, x:" & X'Image); ---------------- end loop ; end T1 ; and similar for Y. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Task_Barriers 2019-07-26 10:38 ` Task_Barriers Gilbert Gosseyn 2019-07-26 11:09 ` Task_Barriers Dmitry A. Kazakov 2019-07-26 15:03 ` Task_Barriers Simon Wright @ 2019-07-27 0:10 ` Dennis Lee Bieber 2 siblings, 0 replies; 12+ messages in thread From: Dennis Lee Bieber @ 2019-07-27 0:10 UTC (permalink / raw) On Fri, 26 Jul 2019 03:38:36 -0700 (PDT), Gilbert Gosseyn <hnptz@yahoo.de> declaimed the following: >On Thursday, July 25, 2019 at 10:17:47 PM UTC+2, Simon Wright wrote: >> >> > although it should stop when reaching an internal count number >> >> What internal count number is that? > >1 with Ada . Text IO , Ada . Synchronous_Barriers ; >2 use Ada . Text IO , Ada . Synchronous_Barriers ; >4 procedure Task_Barriers is >5 NT: constant :=2; >6 SB: Ada.Synchronous_Barriers.Synchronous_Barrier (NT) ; >7 Notified : Boolean:= False ; >8 task T1 ; >9 task T2 ; >10 >11 X: I n t e g e r :=0; >12 Y: I n t e g e r :=1; >13 >14 task body T1 is >15 begin >16 loop >17 delay 1.0 ; >18 Wait_For_Release (SB, Notified ) ; >19 X:=X+1; >20 end loop ; >21 end T1 ; >22 >23 task body T2 i s >24 begin >25 loop >26 delay 1.0 ; >27 Wait_For_Release (SB, Notified ) ; >28 Y:=Y+1; >29 end loop ; >30 end T2 ; >31 begin >32 nul l ; >33 end Task_Ba r r i e r s ; > >In this Task Barriers, procedure Task_Barriers is the parent of task T1 and task >T2. There are two synchronization channels about between two tasks. Line 18 is >sending a message that is meaning the number of blocked tasks associated with the Line 18 doesn't send anything... It invokes a method on the barrier object -- the barrier object increments its internal count of how many tasks are waiting (and blocks the calling task if the count is less than the threshold). >Synchronous Barrier object is equal to the threshold, to the line 28 that is receiving >this message and the statement is starting to execute. Here, the threshold is set to >2. In the same way, Line 27 is labeled with sending the message that the blocked >tasks are released, while Line 19 is receiving it and starting to execute. > Same -- line 27 is invoking the barrier method which causes an increment in the count of waiting tasks. When the count reaches the threshold the barrier releases ALL waiting tasks to continue, and the counter is reset to 0. There is nothing in the code that determines what order the two tasks invoke the barrier wait method. Similarly, there is nothing making use of the (randomly) set "notified" -- all that is known is that one of the two tasks will receive "True" and the other will receive "False"... but ALL tasks were released, none are waiting. {I suspect the simplest runtime is to set notified True for the task that actually triggered the threshold and leave all the other released tasks with a False} Both tasks will loop, and invoke the wait call again. The first one to do so will be blocked (counter incremented to 1), the second will increment the counter to 2, the barrier will unblock all tasks and set the counter to 0... Repeat for 68 years... -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-07-27 0:10 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-25 16:32 Task_Barriers Gilbert Gosseyn 2019-07-25 16:43 ` Task_Barriers Dmitry A. Kazakov 2019-07-25 18:56 ` Task_Barriers Dennis Lee Bieber 2019-07-25 20:11 ` Task_Barriers Jeffrey R. Carter 2019-07-25 20:17 ` Task_Barriers Simon Wright 2019-07-25 21:59 ` Task_Barriers Randy Brukardt 2019-07-26 7:52 ` Task_Barriers Simon Wright 2019-07-26 23:59 ` Task_Barriers Dennis Lee Bieber 2019-07-26 10:38 ` Task_Barriers Gilbert Gosseyn 2019-07-26 11:09 ` Task_Barriers Dmitry A. Kazakov 2019-07-26 15:03 ` Task_Barriers Simon Wright 2019-07-27 0:10 ` Task_Barriers Dennis Lee Bieber
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox