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