RE: JavaMemoryModel: init methods

From: Boehm, Hans (
Date: Mon Oct 02 2000 - 17:24:43 EDT

> -----Original Message-----
> From: Jeffrey G. Bogda []
> (When I say "properly
> synchronized," I mean
> that all threads lock the same lock before accessing a shared
> field or object.
> Are properly synchronized programs even attainable?)
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.
> > "Boehm, Hans" wrote:
> > 2) It can often be used to ensure that another thread has
> made sufficient
> > progress, e.g. if a parent thread holds the lock during
> thread creation, the
> > child may acquire and immediately release it to ensure that
> the parent has
> > finished some work associated with thread creation.
> In this situation, if I understand it correctly, a parent thread is
> synchronizing on some object and a child thread is
> synchronizing on the same
> object. This object is accessible by multiple threads and hence not
> thread-local. You cannot remove the child's empty
> synchronization block if the
> parent is doing some work that is visible to the child.
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?

JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT