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
[EMAIL PROTECTED] http://per.bothner.com/
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
