Re: shared variables in parfor()

[Max Alekseyev <maxale@gmail.com>]

"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 <rvtol@isolution.nl> 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