i rewrote a complete threaded routine both with guile and racket creating
threads and waiting they finish :
;; run the parallel code
{threads <+ (map (λ (seg) (call-with-new-thread
(λ () (proc-unify-minterms-seg seg))))
segmts)}
(nodebug
(display-nl "waiting for threads to finish..."))
;; wait for threads to finish
(map (λ (thread) (join-thread thread)) ;;(+ start-time max-sleep)))
threads)
it does not seems to block but it is a bit slower than on a single CPU.
i have this config:
Puce : Apple M1
Nombre total de cœurs : 8 (4 performance et 4 efficacité)
it is better on a single cpu than with all the cores...
i read all the doc of Posix Thread, i admit Scheme is not C , i read on
forums a few about C and Scheme comparaison.
In any thread local variables should be on the stack of each thread.
The only doubt i have is in Scheme (but the same question exist in C) what
portions of code are or not copied in any thread? for this reason i tried
to encapsulate all the procedures used in // as internals defines in the
procedure passed at call-with-new-thread hoping they are copied in each
threads. I hope the basic scheme procedures are reentrant...
I have no explaination why is it even a bit slower on multiple core than on
one.
Regards,
Damien
On Thu, Nov 10, 2022 at 6:07 PM Olivier Dion <olivier.d...@polymtl.ca>
wrote:
> On Thu, 10 Nov 2022, Damien Mattei <damien.mat...@gmail.com> wrote:
> > Hello Zelphir,
> >
> > i finally find a possible cause of no speed up of my code, i find that
> > using your code the procedure keep blocked on the first 'touch at line 27
> > here:
> >
>
> I have found a possible deadlock with Guile's mutex. In some very rare
> cases, ice-9 futures deadlock because of it.
>
> Maybe it's not the case here I haven't read the code you've mentioned.
> Just letting you know.
>
> --
> Olivier Dion
> oldiob.dev
>
