Locking allocations

vkondratiuk · January 26, 2025, 4:22pm

Hey folks!

I’ve been learning more about multithreading and decided to implement ThreadPool from scratch for educational purposes. I’ve used standard library as a reference. The one thing I seem to missunderstand is in the .spawn() method:

Why do we lock the mutex before and not after the Closure allocation? Isn’t allocating on heap - thread-safe? I thought we would only want to lock the mutex on run_queue mutation and thus reduce the critical section

github.com

ziglang/zig/blob/92b20e42162675d35ffd27845e66b0f9213c00c2/lib/std/Thread/Pool.zig#L245


      
                  // The thread pool's allocator is protected by the mutex.
                  const mutex = &closure.pool.mutex;
                  mutex.lock();
                  defer mutex.unlock();
          
                  closure.pool.allocator.destroy(closure);
              }
          };
          
          {
              pool.mutex.lock();
              defer pool.mutex.unlock();
          
              const closure = try pool.allocator.create(Closure);
              closure.* = .{
                  .arguments = args,
                  .pool = pool,
              };
          
              pool.run_queue.prepend(&closure.run_node);
          }

AndrewKraevskii · January 26, 2025, 5:05pm

It is only threadsafe if you using threadsafe allocator like std.heap.GeneralPurposeAllocator and std.heap.c_allocator.
Almost every other allocator in std is not threadsafe.

Also std.heap.GeneralPurposeAllocator can be configured to be not thread safe.