That was exactly what I demonstrated in another mail on this thread:
final OpenBitSet mybits = new OpenBitSet(size) {{
fastSet(1); fastSet(2);...
}};
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]
> -----Original Message-----
> From: Nader, John P [mailto:[email protected]]
> Sent: Thursday, April 28, 2011 4:21 PM
> To: [email protected]
> Subject: RE: Immutable OpenBitSet?
>
> I agree that Trejkaz's example is correct and consistent with both the JLS
> spec
> and "Java Concurrency in Practice", by Goetz.
>
> Without synchronization, the final keyword is necessary to ensure all values
> set on a long[] in a constructor are seen by other threads in the state they
> were when the constructor completed. This keyword allows java to insert
> the appropriate read barriers on the first read of the object, without the
> overhead of read barriers repeatedly on every read of the object.
>
> The object construction guarantees are not enough for the long[] because
> these only guarantee you will see the initial array of zero's. To guarantee
> safety on the subsequent writes to the long[] during the OpenBitSet
> constructor, the final keyword ensure those writes will be flushed to main
> memory when construction completes prior to any other thread getting a
> reference to the object.
>
> A value holder that holds a final reference to the OpenBitSet is definitely an
> option as it offers that same protection.
>
>
> -----Original Message-----
> From: Trejkaz [mailto:[email protected]]
> Sent: Thursday, April 28, 2011 8:45 AM
> To: [email protected]
> Subject: Re: Immutable OpenBitSet?
>
> On Thu, Apr 28, 2011 at 6:13 PM, Uwe Schindler <[email protected]> wrote:
> > In general a *newly* created object that was not yet seen by any other
> > thread is always safe. This is why I said, set all bits in the ctor.
> > This is easy to understand: Before the ctor returns, the object's
> > contents and all references like arrays are not seen by any other thread
> (that's guaranteed).
>
> Section 17.5 of the JLS gives the following example:
>
> class FinalFieldExample {
> final int x;
> int y;
> static FinalFieldExample f;
> public FinalFieldExample() {
> x = 3;
> y = 4;
> }
> static void writer() {
> f = new FinalFieldExample();
> }
> static void reader() {
> if (f != null) {
> int i = f.x; // guaranteed to see 3
> int j = f.y; // could see 0
> }
> }
> }
>
> Essentially, there is no guarantee that the work in the constructor has been
> completed when another thread gets a reference to the object.
> To make the guarantee, use the final keyword.
>
> It seems like this contradicts the claim above, but maybe I'm missing
> something.
>
> TX
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
