fix: tform: potential crash due to race when MODMAX/MODMIN

[jodavies]

A worker could free a dollar variable's data, while another worker is trying to read it. Lock the dollar variable before working out its RHS in case the RHS depends on the dollar variable that is being assigned.

This closes #147 and #796 , though #796 contains more discussion for the future.

[tueda]

I wonder if the CI failure might be related to awalsh128/cache-apt-pkgs-action#187. When I print the Valgrind errors, it seems like it could be a libc6-dbg incompatibility (?)

Valgrind errors

==4640== Memcheck, a memory error detector
==4640== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==4640== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==4640== Command: /home/runner/work/form/form/sources/vorm /tmp/form_check_20260213-4633-ehml65/ver_20260213-4633-uya517/ver.frm
==4640== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

[coveralls]

coverage: 58.029% (-0.01%) from 58.04%
when pulling f81e0af on jodavies:dollar-modopt-max
into 9b0d11c on form-dev:master.

[jodavies]

For the record, there is a 1-2% performance regression in tests which use moduleoption, maximum etc (forcer, mincer). But I think we can merge this for now, and maybe improve how those dollar types are handled (no locks, taking the maximum only at the end) in the future.

[tueda]

Here are the benchmark results for my system (Intel Core i9-12900, Ubuntu 20.04, x86_64) with tform -w8. I don't see much difference overall.

Benchmark	Speedup	95% bootstrap CI
chromatic	0.99	[0.99, 0.99]
color	1.01	[1.01, 1.02]
fmft	1.01	[1.00, 1.01]
forcer	1.00	[1.00, 1.00]
forcer-exp	1.00	[0.99, 1.00]
mbox1l	0.99	[0.99, 1.00]
minceex	1.00	[1.00, 1.00]
mincer	1.01	[1.00, 1.01]
sort-disk	1.00	[1.00, 1.01]
sort-large	1.00	[0.98, 1.01]
sort-small	1.00	[0.99, 1.00]
trace	0.98	[0.98, 0.99]

Details

Speedup of B over A (mean) = (mean time of A) / (mean time of B)

A:

TFORM 5.0.0 (Jan 27 2026, v5.0.0)
-backtrace  +flint=3.4.0  +gmp=6.3.0   -mpi    +pthreads  +zlib=1.2.11
-debugging  +float        +mpfr=4.2.2  +posix  -windows   +zstd=1.4.4
Compiler: GCC 10.5.0
Architecture: x86_64

B:

TFORM 5.0.0 (Feb 11 2026, v5.0.0-1-gf81e0af)
-backtrace  +flint=3.4.0  +gmp=6.3.0   -mpi    +pthreads  +zlib=1.2.11
-debugging  +float        +mpfr=4.2.2  +posix  -windows   +zstd=1.4.4
Compiler: GCC 10.5.0
Architecture: x86_64

Paired runs with n = 30 per benchmark. Used the scripts from this snapshot. The binaries were built for the x86-64-v1 baseline.

Environment:

OS	Ubuntu 20.04.6 LTS
Kernel	Linux 5.15.0-84-generic
Architecture	x86_64
CPU	Intel Core i9-12900
CPU configuration	16 cores / 24 threads (8 P-cores + 8 E-cores)
Memory	62.6 GiB
Storage	WD_BLACK SN770 1TB NVMe SSD