William D Clinger wrote:
> As an implementor of Scheme, I have had to consider a
> variety of possible representations for R6RS strings.
> A succinct comparison of five plausible representations
> can be found at
>
> 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.
On the other hand, I don't think there is much reason to
bother. I cannot sea how an application can be other
than seriously buggy if one thread tries to read a string
while another thread is updating it without first acquiring
a lock.
Of course one would like to be sure that such a bug doesn't
trash the internal data structures, such as the gc.
--
--Per Bothner
per_at_bothner.com http://per.bothner.com/
Received on Fri Mar 23 2007 - 23:59:15 UTC