[Lazarus] Threads in Lazarus code base

[Mattias Gärtner]

Zitat von Dariusz Mazur <darekm at emadar.com>:

> [...]
> Most of programs are huge count of simple computing. There are many  
> places, that things may run parallel without pain. But very often  
> this places are computing short, thus very often overhead of  
> starting thread is bigger than using second core. But CILK  
> potentially (I can prof that, only imagine) reduce this overhead.  
> Second : its very readability solution, and compiler potentially can  
> warning about some danger . If we try to concurrency smaller things,  
> without loss efficiency, danger   will be minimize

Start a wiki page with a proposal for the syntax.
Create a unit like mtprocs that demonstrates CILK and how the syntax  
should be converted by the compiler.
Find someone to implement and, more important, maintain this.
Then there is a good chance to get this into the fpc main branch.


> [...]
>> Even the mtprocs does that.
>> http://wiki.lazarus.freepascal.org/Parallel_procedures#Features
> realy?
> cite:" a procedure or method is executed with an Index running from  
> an arbitrary StartIndex to an arbitrary EndIndex"
>
> assigning iteration to threads are done on start loop, eq. we must  
> know count of iteration.
> what when iteration 1 is ten times longer than rest?

Then the other threads will sleep OR if this is a nested sub procedure  
the other threads will continue on the other work.
For example:

for i:=1 to 10 paralleldo
   for j:=1 to 10 paralleldo begin
     if j=1 then DoAlotOfWork else DoLittleWork;
   end;

With mtprocs all threads will work until the end when the everything  
was done except the last DoAlotOfWork, which is then executed by only  
one thread.

mtprocs is just a unit, it can not auto parallelize DoAlotOfWork as a  
compiler could.


> [...]
> I thinking about Fifo queue, I use one Lock free,
> its need 16 byte per spawn (func addres, param and result)
> time of swich less than 1us

Are you sure about the 1us switch? The algorithm looks more dramatic.


> problem is with assigning local stack per task, my asm is too weak.

Mattias