Re: Guile FFI: resizable vector problem

Matthew Dempsky <[email protected]> writes:

> Pika's FFI will handle resizable vectors and threading fine because
> users never get pointers to the vector contents -- they can only do
> vector-ref and vector-set! operations on them.

That's true only if you can implement vector-ref and vector-set! as
atomic operations with respect to thread scheduling (simplest case),
or (more generally) if you remain consistent with an interleaving
semantics (not necessarily the one that actually occured) (can be hard
to prove).

The problem is that vector-ref would typically be implemented using
two atomic steps:

  (1) fetch the pointer to the vector
  (2) fetch an entry in that vector

The crucial issue is: what happens if the thread executing the
sequence of two steps above is preempted by the scheduler between
steps 1 and 2?  Some other threads might then do arbitrary things to
the vector, such as resizing it.  You probably wouldn't want to incur
a mutex overhead for every access.  Also, what if the GC kicks in?

Possibly, you have already addressed and resolved these issues, but
that was not apparent to me from the postings.

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE