Steel Bank Common Lisp

Bruno Daniel <bruno.daniel@...> writes:

> Dear developers,
> 
> is it safe to create a hash table in one thread and allow it to self-expand
> (e.g. by (make-hash-table :test #'eql :size 10000
>                    :rehash-size 2d0 :rehash-threshold 0.5))
> and then use it from another thread? What happens if it is expanded while some
> new entry is added from another thread?

Currently hash-tables are protected by spinlocks, so two threads can't
be accessing the same table at the same time. This is however not a
documented property of the public interface, and is likely to change
in the very near future to a situation where: multiple concurrent
readers on the same hash-table are safe, but having a writer thread +
another concurrent thread doing either reads or writes is unsafe. Thus
application level locks will be needed in the latter case.

> What happens if the garbage collector is moving a data structure that is
> simultaneously accessed from another thread? Say you have created an array 
> by (setq arr (make-array 100)) and the garbage collector is moving
> it while another thread executes (setf (aref arr 3) (list 1 2))?

That can't happen. There will be a reference to ARR in a register of
thread 2, which the gc will treat as a conservative pointer, and thus
not move the array.
 
> If you don't pass an array to any other thread, will it stay untouched by the
> garbage collector runs of other threads?

There's just one gc, not individual gcs per thread.

> What is the answer to these questions if a foreign library creates threads on
> its own and then calls some Lisp functions via callbacks?

You're going to lose horribly. All threads that can run Lisp code must
have been created by sbcl, for all kinds of reasons.

-- 
Juho Snellman

Dear Juho,

thank you very much for your enlightening remarks.

> Currently hash-tables are protected by spinlocks, so two threads can't
> be accessing the same table at the same time. This is however not a
> documented property of the public interface, and is likely to change
> in the very near future to a situation where: multiple concurrent
> readers on the same hash-table are safe, but having a writer thread +
> another concurrent thread doing either reads or writes is unsafe. Thus
> application level locks will be needed in the latter case.

Ok, I understand that. I assume the code enlarging the hash on demand will be
triggered in the same thread that intended to add an entry to the hash; so
there will be no problem there either.

> That can't happen. There will be a reference to ARR in a register of
> thread 2, which the gc will treat as a conservative pointer, and thus
> not move the array.

I see. That's great.

> There's just one gc, not individual gcs per thread.

Does the garbage collector suspend all other threads while it is working?

> You're going to lose horribly. All threads that can run Lisp code must
> have been created by sbcl, for all kinds of reasons.

Ok, so I'll have to subclass C++ classes like this one in order to make VTK or
other libraries fully functional in Lisp:
http://www.vtk.org/doc/nightly/html/classvtkMultiThreader.html

Best regards,
  Bruno Daniel