At 06:45 AM 26/10/2003 -0500, Eliot Moss wrote:
>One quick comment: Sylvia, you seem to be meaning stop-the-world
>collection, yet in a highly concurrent system one might well use concurrent
>collection, which is likely to synchronize on individual objects. Does that
>make a difference to your argument?
I'm not sure that I've actually presented an argument as such. Most of what
I said was a description of the requirements. My comment at the end with
the Barrier class implementation was simply an example of an implementation
that I believe does work in the context of a stop-the-world collector, and
in the absence of aggressive optimisation.
The main issue probably relates to the existence of the points x'. I've
assumed that it will be possible for the system to find an x' for each
thread that definitely happens after a1. I suppose I've also assumed that
it will occur sufficiently soon after a1 for it to be useful. In
extremis an implementation might have to force the existence of an x', but
I wonder whether any current real JVMs would have this problem. I mention
again that it is not a requirement that all the x' occur concurrently, so
the x' do not in themselves require a stop-the-world approach.
As processors get faster, memory caches larger, and multi-processor systems
more widely used, the relative cost of synchronization is going to rise
inexorably. We really need a less costly method of dealing with those parts
of the system that do not demand immediate synchronization.
Sylvia.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:52 EDT