Task_Barriers

Task_Barriers

[Gilbert Gosseyn]

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?

Re: Task_Barriers

[Dmitry A. Kazakov]

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

Re: Task_Barriers

[Dennis Lee Bieber]

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/

Re: Task_Barriers

[Jeffrey R. Carter]

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

Re: Task_Barriers

[Simon Wright]

Gilbert Gosseyn <hnptz@yahoo.de> writes:

> although it should stop when reaching an internal count number

What internal count number is that?

Re: Task_Barriers

[Randy Brukardt]

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? 

Re: Task_Barriers

[Simon Wright]

"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".

Re: Task_Barriers

[Gilbert Gosseyn]

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?

Re: Task_Barriers

[Dmitry A. Kazakov]

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

Re: Task_Barriers

[Simon Wright]

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.

Re: Task_Barriers

[Dennis Lee Bieber]

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/

Re: Task_Barriers

[Dennis Lee Bieber]

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/