I'm not sure I follow all the issues here, so I'll try to fill in some
details. I'll assume that the Bean value constructed in the below example
is eventually stored in a static field B, which is accessed by multiple
threads. I can think of three possible ways to add synchronization here to
make this correct:
1) Synchronize around all reads and writes to B and its fields. Should work
on current implementations. Moderately expensive to very expensive, though
perhaps not in the Beans context?. (My experience is that synchronization
costs currently vary greatly among VMs. Once you fix all the remaining VMs
to do something intelligent, they will still vary quite a bit, since there
is substantial variation in the cost of a compare-and-swap. On some
architectures, the best case cost is certainly in the 10s of cycles. On
X86, it usually appears to be relatively cheap, in spite of claims I've
heard to the contrary.)
2) Make B volatile. Doesn't work with current implementations. Cheaper,
but probably not free. On access to B, it prevents later memory operations
from being initiated before the read of B is complete. I think this doesn't
matter for B's fields, but it does matter for unrelated accesses that happen
to follow the B access. My guess is that the average penalty will be small,
but the worst case penalty is that you can no longer hide a cache miss, and
thus lose at least tens of cycles on every access to B.
3) (How applicable is this to real cases?) The construction synchronizes.
Have other threads synchronize once to observe that B has been initialized.
Then access B without synchronization. This seems to be the cheapest (when
the structure of the code allows it) and most portable, but starts to look a
lot like a programmer introduced memory barrier.
Hans
> -----Original Message-----
> From: Doug Lea [mailto:dl@cs.oswego.edu]
> Sent: Friday, September 29, 2000 5:41 AM
> To: Jeffrey G. Bogda
> Cc: JMM
> Subject: Re: JavaMemoryModel: init methods
>
>
> > I just want to make two comments about the Bean-style construction.
> >
> > > Bean bean = new Bean();
> > > bean.setFoo(fooValue);
> > > bean.setBar(barValue);
> > > return bean;
> >
> > 1. Is it really that bad that synchronization is needed for
> this type of
> > construction?
>
> No, it's not bad at all. Except that programmers are known to not do
> it in many cases where they ought to. People are known to make lots of
> other sync errors too. The only thing that makes this one a little
> uncomfortable is that, when the fields foo, bar in above example are
> conceptually final-like write-once values, people may wrongly believe
> that they don't need synch. But again, I don't think this is a
> solvable, or even serious problem for JMM.
>
>
> > 2. It seems to me that the "problem" with Beans is that we can't
> > initialize them in the constructor. What if that weren't the case?
>
> What if pigs could fly? :-)
>
> I don't think there's any way we are going to change the rule that
> beans must have no-arg constructors.
>
> -Doug
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
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