I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors.
Per Bothner wrote:
> > http://larceny.ccs.neu.edu/larceny-trac/wiki/StringRepresentations
>
> > On architectures that support atomic update of 16-bit quantities
> > aligned on double-byte boundaries, storing a non-supplementary
> > character into a record2 string can be done without locking.
>
> I'm not a lock/multi-processing expert, but my intuition is
> that every string-set and string-ref requires a lock if you
> want to allow concurrent updates. Assume a multi-core CPU
> with separate caches, and each of the record, the main array
> and the auxiliary array are in separate cache segments that
> may be flushed independently. I suspect you have to use a
> lock (or cache-flush instruction) on *both* set and ref.
You need a store/load memory barrier coming out of the
string-set!. That's not the same as a lock.
In Java and pthreads, that memory barrier (if needed on
the machine architecture) is performed when you release
a lock, so acquiring and releasing a lock is one way to
execute the memory barrier. It might even be the most
convenient way; if so, that's a limitation of the memory
models used by Java and pthreads, and not a limitation
of the machine architecture.
Note also that the paragraph you quoted applied only to
"architectures that support atomic update of 16-bit
quantities aligned on double-byte boundaries." On other
architectures, every string-set! would involve a lock.
With the record2 representation, on most architectures,
the string-ref procedure shouldn't involve locking or
synchronization unless its access of the main array yields
a surrogate.
I miscounted, by the way. The wiki page describes only
four plausible representations.
Will
Received on Sat Mar 24 2007 - 09:27:58 UTC