Re: Maxima and thread safety

I would be interested to hear from the community about problems they've
tackled with Maxima where compute time was the primary challenge.

Then we could think about helping to make them faster, whether by
parallelization, new Maxima functionality, improved Maxima algorithms,
improved application code, or some other approach. Or maybe suggesting some
other, more suitable, tool.


On Tue, Jun 9, 2026 at 12:42 PM David Scherfgen via Maxima-discuss <
[email protected]> wrote:

> Yes, but we try it with the ..._threads.lisp file. The one you tried uses
> multiple processes, which are completely isolated from each other.
>
> Leo Butler <[email protected]> schrieb am Di., 9. Juni 2026, 18:25:
>
>> Hi David,
>>
>> I cannot reproduce your crash using `distribute_over_tranches_mt.lisp'
>> from Michel's github repo.
>>
>> I played around with the number of threads (1, 4, 8) and your example
>> works
>> fine and it clearly is using multiple threads.
>>
>> Leo
>>
>> Maxima-version: "branch_5_49_base_416_g162a6093a_dirty"
>> Maxima build date: "2026-06-08 12:29:08"
>> Host type: "x86_64-unknown-linux-gnu"
>> Lisp implementation type: "SBCL"
>> Lisp implementation version: "2.6.4.debian"
>> User dir: "/dev/null"
>> Temp dir: "/tmp"
>> Object dir:
>> "/home/butlerlt/maxima/sandbox/git/maxima-code/binary/branch_5_49_base_416_g162a6093a_dirty/sbcl/2_6_4_debian"
>> Frontend: false
>>
>>
>> On Tue, Jun 09 2026, David Scherfgen via Maxima-discuss <
>> [email protected]> wrote:
>>
>> > 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
>> >
>>
>> --
>> ---
>> Best regards,
>> Dr Butler
>
> _______________________________________________
> 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