using mpz_t and threads

[Jim White]

> The freelist must be a global and is modified each 
> time I create a new value, which is with
> every expression in a functional language.  I am
> afraid if I have to lock a mutex this often it will
> hurt performance worse than the individual
> allocations would.

I assume that your performance concerns relate to
contention, not the intrinsic cost of using mutexes -
when implemented sensibly in your OS, testing a lock
really boils down to a memory location test-and-set
instruction. 

The question then, is just how likely contention is
likely to occur in your system. If your model really
does involve multiple concurrent threads evaluating
expressions then there are various ways to reduce the
probability of contention.

The simplest is to allocate each thread a block of
mpz's, so that in most cases a thread will only need
to procure the lock when it starts.

When a particular expression requires more mpz's than
are currently allocated, the thread requests another
block. Contention is minimized by choosing appropriate
block sizes.

Refinements to this method might involve your parser
making intelligent predictions of the number of mpz's
required by a new thread, and passing this number to
the mpz block allocator.


Cheers

Jim White