--qx18Y/MDA8SbomlbQdJ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2007-07-18 at 11:29 +0900, MenTaLguY wrote:
> in reality, however, it's also important to protect
> the code from compiler (and CPU) optimizations which will alter its
> behavior in undesirable ways if it is used in a multi-threaded context
> (e.g. it becomes possible for the reader to see the writer's addition of
> the object but see the object in an uninitalized state!).

It is worth noting that these are not issues if you're only writing for
Ruby 1.8, which has neither an optimizing compiler nor native threads
(where instruction ordering and cache effects become a consideration).

So, does that mean a Spin Buffer implementation would theoretically be
okay for Ruby 1.8?  Maybe as far as those issues go.  But note that the
author himself identifies a number of issues with spin buffers when the
readers and writers get out of sync, including poor performance and the
reader getting "stuck" on a non-empty buffer if it hits a buffer
boundary when no writers are writing.  Those are actually inherent to
the data structure's design.

-mental

--qx18Y/MDA8SbomlbQdJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGnYD+SuZBmZzm14ERAsxWAJ92RZfVYlFqKaGEbeU327YaEs2wWgCgmLMn
U17NBl6rgZNLvBnqdn5BdAQ ¨Â-----END PGP SIGNATURE-----

--qx18Y/MDA8SbomlbQdJ--