Re: Maxima and thread safety

While I agree with the general explanation here, I have a different view of
parallelism.

It is possible to try executing a computation in many threads
(a) for fun, to see if it can be done
(b) for intellectual rearrangement or simplicity.  (E Dijkstra, I recall,
argued that
one should think that essentially everything is parallel except
for the things that somehow require serial execution .)
(c) testing software or hardware to see if they work.

Here's my view, which may be old-fashioned, and is colored by "symbolic
computation" applications and systems,
maybe contrarian in these days of GPU enthusiasm.
(a) There are just a few area of symbolic computation where execution time
is excessive.  I am aware of one,
having to do with celestial mechanics / orbit calculations, where the
computation has to do with multiplication
of sine/ cosine series with polynomial coefficients.
There are presumably others, and they might be essentially those
computations done in a numerical context
(linear algebra -- matrix computations, matrix inversion) or possibly
search or data-base access, in which there
is a symbolic analog.
(b) Rewriting parts of such symbolic computation to run in parallel might
be of use. There are some models for
doing this , base on the numerical versions.
(c) There are some specific hacks to do symbolic math tasks in parallel
such as doing a computation in a number of
different finite fields simultaneously,  or using Fast Fourier Transform
(FFT) methods for (say) polynomial multiplication.
Or something encoded as a dense or sparse matrix.
These presumably can be coded, perhaps in lisp /C/assembler and used from
usual symbolic computation routines.
E.g. something like encode_poly_as_sparse_matrix(p1).   or
poly_mult_by_FFT(p1,p2)

So there's use for parallelism in principle.   Arguing against this is that
the more likely barrier to completing a computation
is the amount of memory available (though that is growing), or the access
time for memory (can we compute in highest-speed
cache or locally allocated space).
  Random user-level multiprogramming, not yet convincing "for real".
Though still there are arguments for fun, thinking, testing,
RJF


On Tue, Jun 9, 2026 at 7:40 AM Michel Talon <[email protected]> wrote:

> 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