[elephant-devel] Serialization

[Alain Picard]

Ian Eslick <eslick at csail.mit.edu> writes:

> Elephant users and developers,
>
> 1) Special start-elephant-thread macro which creates dynamic bindings
> for the new process of a global special variable that maintains the
> circularity buffer; this will allow us to be very efficient but requires
> elephant-specific code on thread creation for safe threading

As long as you document and export the special which needs to be
bound, this is not a big deal; certainly, in my code, I already
have specialized thread-starting functions which for the same
purpose.  But I'd much prefer having the special exported than
the thread-making function.  (Could have both, of course).

This option seems like a win to me.

> 2) Bind a C-library which provides a CPU independent compare-and-swap
> instruction and/or a lock-free queue so we can share a pool of
> circularity buffers among processes in a lock-free way

This would have to be well hidden and transparent, but would be OK.

> 3) It occurs to me that most lisps do not allow C code to be run
> concurrently from multiple threads - perhaps just implementing a mutex
> in C would be enough to provide a cheap way of updating head and tail
> pointers in the queue.  Capturing and releasing would be atomic.  Is
> this true for all lisps?  I know it's true for Allegro.  It would be a
> hack, but a fairly harmless one given our existing dependence on the
> memutil library.

It's pretty clear that SBCL is aiming for a full multicore support,
and the commercial vendors will have to follow suit; they'll be
dead in the water when 4/8 core cpus are commonplace and their lisps
impose stringent restrictions on the programmer.  So I'd say it's
best to not make assumptions based on what implementations "currently do".


> 4) Stick with the portable locking approach already implemented

Doesn't seem good enough -- the point of a multithread lisp and
berkeley DB is to allow concurrent access to the data.  Serializing
access... well... the cure is worse than the disease.

> Thoughts?

Just my 2 cents; it's your show.  :-)


                           --ap