"Boehm, Hans" wrote:
> It seems to me it's unattainable for most large programs. There are too
> many ways to cheat and get better performance. And some of the more
> interesting cheats are even correct, e.g. updating a cache with an atomic
> pointer assignment and not locking on lookup, or "or"ing boolean results by
> initializing a global to "false" and then asynchronously writing "true" into
> it, potentially from multiple threads. Even if the program in question
> doesn't care enough about performance to do this, one if the library writers
> will have.
It sounds to me like you are saying that properly synchronized programs are
possible, but people aren't going to write them. I agree with you, but I think
it is unfortunate. I would rather see programmers and library writers fully
synchronize their shared data and let the compiler and run-time system worry
about "cheating" in order to improve performance. I guess the only way that is
going to happen is if they fully trust the compiler and run-time system or if
the language somehow requires proper synchronization.
> I think we agree. But it seems to me that this is almost exactly what you
> need to do to remove the synchronization in the beans example? You need to
> recognize that field values are constant once the object becomes public, and
> then remove the synchronization on the bean from field accesses, eventhough
> the bean is accessible from multiple threads? Or did I misunderstand?
In some situations I think it should be possible to detect this. It seems like
you have a particular scenario in mind. Can you give some sample code?
Jeff
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT