Re: shared variables in parfor()

"Untangling" typically bears an overhead and in some cases makes the code
not so straightforward. It's a pity that PARI does not support pthreads'
ability to share memory. For "parfor(i=a,{b},expr1,{r},{expr2})" providing
read-only access to shared memory within expr1, and write access within
expr2 only does not require any locks and would be already a great benefit.

Regards,
Max



On Sat, Jan 18, 2025 at 8:06 AM Ruud H.G. van Tol <[email protected]>
wrote:

>
> On 2025-01-17 21:31, Max Alekseyev wrote:
> > I naively thought that the following code would print a few zeros,
> > which would then follow by all ones:
> >
> > my(q=0); parfor(i=1,10^6, print(q); 0, R, q=1)
> >
> > but it constantly prints zeros. So, the value of q is not shared
> > between threads.
> > What is the right way to create a shared variable (with pthreads if
> > that matters)?
>
> A shared value is a synchronization point, so that would need locks.
> This results in waiting threads, which likely slows things down.
>
> Sometimes a memory-mapped file is used for shared values.
>
> In general, prepare an environment for each thread with start values (Map),
> then let the concurrent threads run (Reduce),
> then post-process their results (Merge).
>
> Essential is that all Reducing writers are independent ("lock-free").
> Such a Map-Reduce-Merge "unit" can be nested, with proper care.
>
> For what case did you want to use a shared variable?
> Then we could try and untangle it.
>
> -- Ruud
>
>
>