comp.lang.ada
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* Re: Task_Barriers
  2019-07-26 10:38  6%   ` Task_Barriers Gilbert Gosseyn
@ 2019-07-27  0:10  0%     ` Dennis Lee Bieber
  0 siblings, 0 replies; 8+ results
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	[relevance 0%]

* Re: Task_Barriers
  @ 2019-07-26 10:38  6%   ` Gilbert Gosseyn
  2019-07-27  0:10  0%     ` Task_Barriers Dennis Lee Bieber
  0 siblings, 1 reply; 8+ results
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	[relevance 6%]

* Re: Task_Barriers
  2019-07-25 16:32  7% Task_Barriers Gilbert Gosseyn
@ 2019-07-25 16:43  0% ` Dmitry A. Kazakov
    1 sibling, 0 replies; 8+ results
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	[relevance 0%]

* Task_Barriers
@ 2019-07-25 16:32  7% Gilbert Gosseyn
  2019-07-25 16:43  0% ` Task_Barriers Dmitry A. Kazakov
    0 siblings, 2 replies; 8+ results
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	[relevance 7%]

* Re: ada.synchronous_barriers incomplete?
  2018-05-01 11:26  5% ada.synchronous_barriers incomplete? hnptz
@ 2018-05-01 12:34  5% ` Dmitry A. Kazakov
  0 siblings, 0 replies; 8+ results
From: Dmitry A. Kazakov @ 2018-05-01 12:34 UTC (permalink / raw)


On 2018-05-01 13:26, hnptz@yahoo.de wrote:
> The rationale_2102 says: "There are many situations where the release of N tasks is required to execute an algorithm in parallel". My question is how to stop N-1 tasks after one of the N tasks has found the required solution before all other N-1 taks?

An atomic Boolean set true by the first task reaching the solution? 
Other task can periodically check the value.

Or it could be the asynchronous transfer of control if the tasks do only 
computations:

    task body Worker is
    begin
       select
          Ready.Wait; -- Protected object implementation of an event
       then abort
          loop -- Incredibly long computations
             ...
             exit when Converged;
             ...
          end loop;
          Ready.Signal; -- I am the first!
       end select;
    end Worker;

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


^ permalink raw reply	[relevance 5%]

* ada.synchronous_barriers incomplete?
@ 2018-05-01 11:26  5% hnptz
  2018-05-01 12:34  5% ` Dmitry A. Kazakov
  0 siblings, 1 reply; 8+ results
From: hnptz @ 2018-05-01 11:26 UTC (permalink / raw)


The rationale_2102 says: "There are many situations where the release of N tasks is required to execute an algorithm in parallel". My question is how to stop N-1 tasks after one of the N tasks has found the required solution before all other N-1 taks?

^ permalink raw reply	[relevance 5%]

* ANN: Paraffin 4.3, Parallelism Generics
@ 2013-06-19  6:41  2% Brad Moore
  0 siblings, 0 replies; 8+ results
From: Brad Moore @ 2013-06-19  6:41 UTC (permalink / raw)


I am pleased to announce Paraffin 4.3.

Paraffin is a set of Ada 2012 generics that may be used to add
parallelism to iterative loops and recursive code.
Older releases (prior to 4.0) also support Ada 2005.

Paraffin includes generics for both Ravenscar and non-Ravenscar use.
The Ravenscar version utilizes static task pools with dispatching
domains intended for real-time programming.

Paraffin also includes Paraffinalia, which is a suit of useful parallel
utilities that utilize the Paraffin generics. These include generics for;
    1) generic to integrating a function in parallel
    2) generic to apply quicksort algorithm in parallel to an array
    3) generic to apply fast fourier transform to an array of data.
    4) generic Red-Black tree container that performs some operations
       in parallel.
    5) function to solve matrices using Gauss-Jordan Elimination
    6) generic to perform prefix sum calculations
    7) generic to perform sequence alignment using the Smith-Waterman
       algorithm to find similar regions between two strings for
       problems such as comparing genetic nucleotide or protein
       sequences, or checking for plagiarism between two text sourcs.

This release has the following notable features;

1) Most importantly, to those who want to compile Paraffin with
    the latest GNAT 2013 GPL release, this version contains bug fixes
    that allow compilation.
2) A new Paraffinalia app has been added. This implements the
    Smith-Waterman dynamic algorithm in parallel. This app performs
    sequence alignment, which means it may be used to find similar
    regions between two text strings. Such an algorithm is of interest
    to genetic comparisons of nucleotide or protein sequences. It may
    also be used to compare two text documents against each other for
    plagiarism, etc.
3) A Ravenscar compliant version of the Smith-Waterman app has also
    been added
4) Several wait-free barriers have been added. These offer several
    advantages over the facilities of Ada.Synchronous_Barriers, in that
    the workers are released in parallel, as opposed to sequentially,
    for barriers that are implemented as protected objects. In addition,
    there is no blocking, no queues, and these new barriers are
    Ravenscar compliant, and objects of these barriers can be declared
    at nested levels in a Ravenscar application, unlike barriers that
    are implemented as protected objects. The last point to note is that
    using these barriers can make a significant improvement in
    performance. The matrix-solving paraffinalia app has been seen to
    complete twice as fast in certain circumstances.
5) A new facility has been added to the work sharing loop iteration
    packages. This is a subprogram, Get_Worker_Id, that allows the
    caller to statically determine which worker will be assigned to a
    particular loop iteration number. This is particularly useful for
    algorithms that use barriers, as typically one needs to know how
    many workers will be synchronizing on the barrier, as well as to
    map intermediate user-defined result arrays with worker numbers.
6) The Smith-Waterman app, the matrix solving app, and the histogram
    cumulative sum paraffinalia apps were modified to use this new
    faclity.

The latest stable release and older releases may be downloaded from;

  https://sourceforge.net/projects/paraffin/files/

For those who want the current development versions of the source they
can download using git (http://git-scm.com/) by issuing the following
commands;

  mkdir sandbox
  cd sandbox
  git clone git://git.code.sf.net/p/paraffin/code paraffin-code


Regards,

   Brad Moore


^ permalink raw reply	[relevance 2%]

* ANN: Paraffin 4.2, Parallelism Generics
@ 2013-05-05 17:18  3% Brad Moore
  0 siblings, 0 replies; 8+ results
From: Brad Moore @ 2013-05-05 17:18 UTC (permalink / raw)


This is a minor update to the Paraffin release 4.1 that was released a 
couple days ago.

This release (4.2) is geared towards getting the Ravenscar version of 
the FFT (Fast Fourier Transform) paraffinalia app to work on Windows, 
and other targets where synchronous barriers are implemented by
protected types.

To achieve this, a new package, called 
Parallel.Simple_Synchronous_Barriers was introduced.

This package provides the services of a barrier when only two tasks
need to wait on the barrier, and is implemented using Ada's suspension
objects, rather than a protected type.

The issue is that on Windows, Ada.Synchronous_Barriers is implemented
by a protected object in GNAT. Ravenscar disallows protected objects
to be declared at a nested level, which is needed by the FFT app.
Since only two tasks ever need to wait on a barrier in the FFT
algorithm, a specialized implementation of a barrier can be constructed
using Ada's suspension objects.

This specialized barrier satisfies the Ravenscar restrictions, but also
is lighter weight, and was deemed worthwhile for use for the 
non-ravenscar version of fft.

As a result of this change, the project file test_ravenscar_fft_linux
was renamed to test_ravenscar_fft, since it should now be portable to
all targets.

The latest stable release and older releases may be downloaded from;

  https://sourceforge.net/projects/paraffin/files/

For those who want the current development versions of the source they
can download using git (http://git-scm.com/) by issuing the following
commands;

  mkdir sandbox
  cd sandbox
  git clone git://git.code.sf.net/p/paraffin/code paraffin-code



^ permalink raw reply	[relevance 3%]

Results 1-8 of 8 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-05-05 17:18  3% ANN: Paraffin 4.2, Parallelism Generics Brad Moore
2013-06-19  6:41  2% ANN: Paraffin 4.3, " Brad Moore
2018-05-01 11:26  5% ada.synchronous_barriers incomplete? hnptz
2018-05-01 12:34  5% ` Dmitry A. Kazakov
2019-07-25 16:32  7% Task_Barriers Gilbert Gosseyn
2019-07-25 16:43  0% ` Task_Barriers Dmitry A. Kazakov
2019-07-25 20:17     ` Task_Barriers Simon Wright
2019-07-26 10:38  6%   ` Task_Barriers Gilbert Gosseyn
2019-07-27  0:10  0%     ` 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