Re: Maxima and thread safety

Of course, the example code could be simplified, it doesn't need two
variables "x_n" and "x_next".

The reason why it doesn't work is that Maxima stores the values of the
variables by binding the symbol to the value. It has no mechanism for
lexical variables. "block" only remembers the variable's value before, and
restores it afterwards. All the threads therefore read and write the same
symbol value and get into each other's way.

One would have to make sure that every thread uses variables with distinct
names, and ideally create them before, so that the "values" list is correct.

David Scherfgen <[email protected]> schrieb am Di., 9. Juni 2026,
17:15:

> Hi Michel,
>
> You might add this to your examples:
>
> distribute_over_tranches(
>   '(block(
>       [x_n: float(N), x_next, i],
>       for i : 1 thru 1000 do (
>           x_next: 0.5 * (x_n + N / x_n),
>           x_n: x_next
>       ),
>       x_n)),
>   N, 1000, 16);
>
> Nothing fancy, it's Newton's algorithm to compute the square root, with a
> fixed number of iterations, just for demonstration purposes.
> Note that I have done everything possible to make sure that the variables
> x_n, x_next, i are local, by using a block.
> But yet, the calculation crashes as soon as one uses more than 1 thread.
> So, the situation is even more delicate than I thought.
>
> Best regards
> David
>
> Am Di., 9. Juni 2026 um 16:45 Uhr schrieb Michel Talon <
> [email protected]>:
>
>> I have updated the README in
>>
>> https://github.com/mtalon/mtalon/tree/master/mtalon/maxima-parallel
>>
>> to reflect David insightful examples.
>>
>> Finally "distribute_over_tranches_thread.lisp" is another way to
>> achieve the same parallelism, using threads in just one Unix
>> process. Here we use the sbcl threading support. For sufficiently
>> independent computations one may expect to get correct behaviour.
>> However if threads modify the internal state of maxima chaos can
>> occur. Examples have been provided by David Scherfgen, notably:
>> distribute_over_tranches('(concat('v, i) :: i), i, 10000, 16)$
>> which under the hood affect the global variable $values, so at the end
>> one gets length($values) different from 10000. The problem is that special
>> variables with global extent are not bound in thread local storage, but
>> can be read and modified independently by all threads. But they are not
>> protected by a mutex.
>> A small lisp program which  shows the behavior of such special global variables is:
>>
>> ;;; We are in main thread
>> (defparameter *x* 0)
>> (format nil "~a" *x*)    ;;; value of global *x* in main thread
>> (let ((*x* 1))
>> a  (format t "~a ~%" *x*)  ;;; value of *x* in main thread TLS
>>   (sb-thread:make-thread (lambda ()   ;;; spawning new thread
>> 			   (format t "~a ~%" *x*) ;;; value of *x* in new thread, the global one.
>> 			   (setq *x* 3)
>> 			   (format t "~a ~%" *x*) ;;; altered value of *x* in new thread
>> 			   "Sorry! *x* in main thread is not isolated.")))
>> (format nil "~a" *x*)     ;;; The global value of *x* has been altered in main thread
>>
>> However i still believe that the threading program may be very useful to distribute a bunch of "ordinary standard"
>> computations over the many cores of modern processors.  For example running the same computation a hundred of times for
>> different values of parameters which may take hours of compute time, will be scaled down basically by the number of cores.
>> Fortunately special variables bound locally in a let form or similar  (this being called dynamically bound) get bound in TLS
>> (thread local storage) which isolates them from thread to thread, so that most parts of maxima can still work OK.
>>
>>
>> Le 07/06/2026 à 16:55, David Scherfgen a écrit :
>>
>>
>> Unfortunately, Maxima has many hidden side effects that are surprising to
>> the average user. The following innocent looking example simply creates
>> Maxima variables v1, v2, v3, ..., v10000 in 16 parallel threads:
>>
>> --
>> Michel Talon
>>
>> _______________________________________________
>> Maxima-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss