From: MenTaLguY <mental@...>
Date: 2005-11-09T13:06:32+09:00
Subject: Re: Checking for race conditions with Ruby threads

--=-wY7jl9Xoxm+nX7w7GiGr
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-11-09 at 09:14 +0900, Wilson Bilkovich wrote:
> Are you saying that race conditions are in general possible to=20
> prove/disprove, or just that my code isn't the way to do it?

Writing unit tests is not the way to go for race conditions -- depending
on system load, phase of the moon, CPU speed, etc, you will get false
negatives sometimes (or sometimes a lot).

There's value in constructing stuff like this to show up such a bug for
debugging, but race conditions just aren't something you can reliably
unit test for.

To prove the absence of a race condition, there's no real alternative[1]
but to look at the code and reason about it.

It's possible that I'm wrong in the practical sense, if the race
condition is extremely egregious, but unless you have precise control
over execution order, if there is a chance for the wrong code to win a
race condition, there is always a chance for the right code to win it
occasionally.

-mental

[1] I think David Overton from Mercury has been working on an automated
checker, but it has inherent limitations.

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

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

iD8DBQBDcXXDcUNIGiXCc4MRAhsxAJ9/Fg0VpMuZdgYxesQ2qULX1jEfwQCffuT0
RZQ2WSBYXFCng/Tr12mjGJw=
=v95r
-----END PGP SIGNATURE-----

--=-wY7jl9Xoxm+nX7w7GiGr--