> I think it is worth noting that there are programs that might be
> deemed "not
> correctly synchronized" by your definition, but are still "correct" in the
> intent of the program (i.e. not broken or wrong). An example is the
> double-check lock idiom where the code within the double-check is
> idempotent. Another example is for caching algorithms that avoid
> synchronization in ways that would cause rare race conditions, but the
> result of such a race condition is not bad, provided that the
> common case is
> for the race to win the way you want it to.
Are you saying that these programs are correct based on the happens-before
based definition that Bill gave earlier but not by the definition I gave?
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT