Re: In case you need to remember...

[anon@att.net]

The truth is Ada is Concurrent which means Ada uses one and only one 
thread for all tasks. 


And on a multiple core system the thread may swap between processors 
during thread scheduling but the Ada code is only one thread under 
the OS.  The RM 2012 does have some multiple processors packages but 
they are not enough routines to build a fully functioning true multiple 
thread for each task.

Now, GNAT using OS_Lib packages does have some OS links that can request 
new thread but these routines are not listed in the RM. Also, GNAT can 
use the Spawn or folk call but it is not recommended due to fact of 
blocking and signal/locks which are unpredictable. (see Note in 
System.OS_Lib.ads) Now in GNAT 2012 release in a month or two this 
may be different.


And example to demonstrated Ada based thread:


with Ada.Text_IO ;
with Ada.Integer_Text_IO ;
with Ada.Task_Identification ;

--  If Ada was multiple tasking using threads then the main procedure 
--  would end and the Task would run in the background similar to 
--  starting a server on any OS. This is, the main procedure would 
--  be use to active the task and then exit. But due to the fact that 
--  Ada is still concurrent the main procedure will finish executing 
--  but will be blocked in "Finalization".  Some resources may be 
--  release but not all. In other words the main procedure will be 
--  blocked and some resources held until the "Task" ends it run or 
--  the operator kills the executing thread which kills both the 
--  main procedure and the task and release all resources.
--
--  Also if you use a thread monitor you will see only one thread
--  was created and is running. And if Ada used multiple threads then 
--  in this program there would be one thread for the main procedure
--  "Test" and a second thread for the task "Task_1". But there is 
--  only one thread indicating that Ada is still concurrent.
--

procedure Test is

  use Ada ;
  use Text_IO ;
  use Integer_Text_IO ;


  task type CPU_TASK is
    entry Run_cpu ;  
  end CPU_TASK ;

  PC : Integer := 55 ;
  Run_Flag : Boolean := False ;

  --  Task is activated once the program begins
  --  If Ada was multiple thread then this task would activated once 
  --  the OS created a new thread entry in the job thread scheduler
  Task_1 : CPU_TASK ;  


  task body CPU_TASK is

    begin -- CPU_TASK 

      Put_Line ( "Processor is Uninitialized" ) ;
      loop
        select
          accept Run_cpu ;      

              -- Run until process is either reset, halted.  

              Put_Line ( "Task is in RUN Mode" ) ;
              Run_Flag := True ;
              loop
                Put_Line ( "Executed Instruction" & PC'img ) ;
                PC := PC + 1 ;
                Delay  0.0 ; -- tells Ada RTL to swap task to main
              end loop ;
              exit ;
        or
         terminate ;
        end select ;
      end loop ;
    end CPU_TASK ;

begin

  Put_Line ( "Reset Processor status" ) ;
  PC := 0 ;
  Delay 0.1 ;
  Put_Line ( "Set processor status to RUN Task" ) ;
  Task_1.Run_cpu ;

  Delay  0.5 ;
  Put_Line ( "Trying to Single Step Task" ) ;


--  Delay  0.1 ;
--  Put_Line ( "Stopping the Task" ) ;
--  Ada.Task_Identification.Abort_Task ( Task_1 ' Identity ) ;

    Put_Line ( "Finished Excution of program" ) ;
end test ;

In <1984433.261.1333725652284.JavaMail.geo-discussion-forums@vbbfr18>, mockturtle <framefritti@gmail.com> writes:
>....how nice is having tasks built-in in your preferred language, I just lan=
>ded over this text (Threads =97 Threat or Menace?)
>
>   http://www.faqs.org/docs/artu/ch07s03.html#id2923889
>
>Just an excerpt:=20
>
>  "Threads are a fertile source of bugs because they can too easily know to=
>o much about each others' internal states. There is no automatic encapsulat=
>ion, as there would be between processes with separate address spaces that =
>must do explicit IPC to communicate. Thus, threaded programs suffer from no=
>t just ordinary contention problems, but from entire new categories of timi=
>ng-dependent bugs that are excruciatingly difficult to even reproduce, let =
>alone fix."
>
>Hmm... Why do I have this warm and cozy feeling? :-)=20
>
>BTW, a curiosity: does the Linux version of GNAT use threads to implement t=
>asks?=20
>
>Riccardo