Common Lisp：lparallel并发赋值数组元素为何出现异常？

先直接给你理清核心问题：并发写入数组的不同元素本身不一定有风险，但你遇到的情况是SBCL对窄位宽数组的内存打包优化引发了竞态条件。

为什么会出现随机未赋值/元素错误？ #

你碰到的问题根源在于SBCL对(unsigned-byte 4)类型数组的存储策略：

• 每个unsigned-byte 4元素仅占4位（半个字节），SBCL会自动把两个相邻的这类元素打包存储在同一个字节里。
• 当多个线程同时修改同一个字节里的两个元素时，就会出现竞态冲突：比如线程A读取字节→修改低4位→写回；线程B同时读取同一个字节→修改高4位→写回，最终其中一个线程的修改会被覆盖，导致对应元素保留初始值0。
• 线程越多、数组越小（元素越密集，相邻元素共享字节的概率越高），这种冲突的概率就越大，所以你会看到未赋值位置随机且数量随线程数增加而变多。

而(unsigned-byte 7)、字符数组、浮点数组等类型的元素，每个都至少占1个完整字节，内存地址完全独立，并发修改时不会互相干扰；CCL可能对窄位宽数组采用了不同的存储实现（比如没有打包，或者内部处理了原子性），所以没有出现问题。

你的疑问解答 #

1. Common Lisp中并发赋值不同数组元素是否存在问题？
   语言标准并没有禁止这种操作，但安全性取决于数组元素的内存布局和CL实现的内存模型。对于内存独立的元素（每个元素占独立内存单元），并发写入是安全的；但像unsigned-byte 4这种被打包到同一内存单元的元素，并发修改相邻元素就会产生竞态条件，导致错误。

2. 是否需要加锁实现同步赋值？
   如果必须使用unsigned-byte 4类型数组，确实需要对共享的内存单元（每两个元素对应的字节）做同步，但全局加锁会完全丧失并发优势，更优的方案有这些：

   • 用原子操作替代锁：比如SBCL的sb-ext:atomic-update，原子性地修改字节中的对应位。例如，修改第i个元素时，先判断它对应字节的高4位还是低4位，再原子更新目标位，这样不需要锁也能保证操作的原子性。
   • 换用宽位宽元素类型：把数组元素类型换成(unsigned-byte 8)，每个元素占1字节，内存完全独立，此时用pdotimes并发写入就不会有冲突，这是最简单的解决方案。
   • 调整pmap-into的使用：如果坚持用pmap-into，先确保位移向量的计算完全正确；如果还是因为元素打包出错，那还是得回到前面两种方案。

另外，用future包裹函数没用的原因是：future只是让函数异步执行，但并没有解决底层内存访问的竞态问题，冲突依然会存在。

内容的提问来源于stack exchange，提问作者phantomics