Re: shared variables in parfor()

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Sat, Jan 18, 2025 at 11:57:50AM -0500, Max Alekseyev wrote:
> "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.

It does require a lock since expr1 and expr2 run at the same time, otherwise
this would lead to a memory leak.
Further it leads directly to a race condition.
The design of GP parallelism is precisely to prevent users to write incorrect
code. Otherwise writing valid parallel code would be out of reach of most users,
especially those who are overoptimistic about parallelism.

Due to an oversight, the default "seriesprecision" is not thread-safe yet.
This will allow us to simulate your code like this:

test()=
{
  my(q=0); 
  default(seriesprecision,16); 
  parfor(i=1,10, print(default(seriesprecision)); 0, R, default(seriesprecision,1))
}

test() triggers a race condition: it displays a random number of time "16" and "1" with probability
depending of nbthreads and whether there are other processes running on your system.
This is unsound. GP parallel design is designed so that results do not depends on the number of threads
and of race conditions.

Cheers,
Bill.