Parametric Initialization On DemandHolder Idiom ?

[Beverly Sanders]

Most of the (interesting) discussion of this example has focused on
the value of f that can be seen when a reference is leaked in the
constructor.  But suppose we got rid of  badHolder and eliminated that
problem.  Wouldn't this program have a race on goodHolder
itself unless something is done to create hb edges?   For example,
by making goodHolder volatile, or ensuring that  goodHolder is assigned
by some thread before other threads that read it are started, or
otherwise "safely publish" the reference?  But if we still need
safe publication, then the special semantics for final fields don't
add anything.  What am I missing?

In this example, safe publication is needed (it is safe when
goodHolder is volatile)


class FinalHolder {
  static [volatile] FinalHolder goodHolder;

final int f;
FinalHolder() {
  f = 1;
}
void printFinal() {
System.out.println(f);
}


Thread1:
Thread2.start();
goodHolder = new FinalHolder();

Thread2:
while(goodHolder==null){}
           //termination guaranteed only if goodHolder volatile
goodHolder.print();
           //if thread gets here, it will print 1 due to
           //correct construction (no leak of ref from consructor)
           //and final field semantics.
           //But if goodHolder volatile, f doesn't need to be
           //final except to ensure that the value is not modified--special
           //treatment in the memory model is not needed.



Thanks,
Beverly Sanders

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Hanson Char]

>On 9/5/07, Beverly Sanders <sanders@...> wrote:
> Most of the (interesting) discussion of this example has focused on
> the value of f that can be seen when a reference is leaked in the
> constructor.  But suppose we got rid of  badHolder and eliminated that
> problem.  Wouldn't this program have a race on goodHolder
> itself unless something is done to create hb edges?

Yes, this program would have a data race.

>For example,
> by making goodHolder volatile, or ensuring that  goodHolder is assigned
> by some thread before other threads that read it are started, or
> otherwise "safely publish" the reference?  But if we still need
> safe publication, then the special semantics for final fields don't
> add anything.  What am I missing?

True, but we don't need safe publication for (correctly constructed)
immutable object in the first place.

> In this example, safe publication is needed (it is safe when
> goodHolder is volatile)

It is safe publication in your example (with the volatile) but it is
not needed in this case, given FinalHolder is immutable and is
correctly/safely constructed.

Cheers,
Hanson Char

>
> class FinalHolder {
>   static [volatile] FinalHolder goodHolder;
>
> final int f;
> FinalHolder() {
>   f = 1;
> }
> void printFinal() {
> System.out.println(f);
> }
>
>
> Thread1:
> Thread2.start();
> goodHolder = new FinalHolder();
>
> Thread2:
> while(goodHolder==null){}
>            //termination guaranteed only if goodHolder volatile
> goodHolder.print();
>            //if thread gets here, it will print 1 due to
>            //correct construction (no leak of ref from consructor)
>            //and final field semantics.
>            //But if goodHolder volatile, f doesn't need to be
>            //final except to ensure that the value is not modified--special
>            //treatment in the memory model is not needed.
>
>
>
> Thanks,
> Beverly Sanders

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Beverly Sanders]

Thanks for the quick reply,

>> On 9/5/07, Beverly Sanders <sanders@...> wrote:
>> Most of the (interesting) discussion of this example has focused on
>> the value of f that can be seen when a reference is leaked in the
>> constructor.  But suppose we got rid of  badHolder and eliminated that
>> problem.  Wouldn't this program have a race on goodHolder itself unless
>> something is done to create hb edges?
>
> Yes, this program would have a data race.
>
>
>> For example,
>> by making goodHolder volatile, or ensuring that  goodHolder is assigned
>> by some thread before other threads that read it are started, or
>> otherwise "safely publish" the reference?  But if we still need safe
>> publication, then the special semantics for final fields don't add
>> anything.  What am I missing?
>
> True, but we don't need safe publication for (correctly constructed)
> immutable object in the first place.
>
>> In this example, safe publication is needed (it is safe when
>> goodHolder is volatile)
>
> It is safe publication in your example (with the volatile) but it is
> not needed in this case, given FinalHolder is immutable and is
> correctly/safely constructed.
>

Safe publication _is_ needed to ensure that thread2 will
terminate, right?  The point is that a data race on the reference to
the published object is probably bad for reasons that may have nothing to
do with the final fields, but that getting rid of that data race also
eliminates the need for the special semantics for final fields for
safely constructed objects.  This latter claim could be wrong--but
if it is, I'd appreciate an explanation.

Thanks.
Beverly Sanders

> Cheers,
> Hanson Char
>
>
>>
>> class FinalHolder { static [volatile] FinalHolder goodHolder;
>>
>> final int f; FinalHolder() {
>> f = 1; }
>> void printFinal() { System.out.println(f);
>> }
>>
>>
>>
>> Thread1:
>> Thread2.start();
>> goodHolder = new FinalHolder();
>>
>> Thread2:
>> while(goodHolder==null){} //termination guaranteed only if goodHolder
>> volatile goodHolder.print(); //if thread gets here, it will print 1 due
>> to //correct construction (no leak of ref from consructor)
>> //and final field semantics.
>> //But if goodHolder volatile, f doesn't need to be
>> //final except to ensure that the value is not modified--special
>> //treatment in the memory model is not needed.
>>
>>
>>
>>
>> Thanks,
>> Beverly Sanders
>>
>
>

--
Beverly A. Sanders, Associate Professor
Department of Computer & Information Science & Engineering
P.O. Box 116120
University of Florida
Gainesville, FL 32611-6120
www.cise.ufl.edu/~sanders
tel: [phone]
fax: [phone]

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Hanson Char]

On 9/5/07, Beverly Sanders <sanders@...> wrote:

> In this example, safe publication is needed (it is safe when
> goodHolder is volatile)
>
> class FinalHolder {
>   static [volatile] FinalHolder goodHolder;
>
> final int f;
> FinalHolder() {
>   f = 1;
> }
> void printFinal() {
> System.out.println(f);
> }
>
> Thread1:
> Thread2.start();
> goodHolder = new FinalHolder();
>
> Thread2:
> while(goodHolder==null){}
>            //termination guaranteed only if goodHolder volatile

True.

> goodHolder.print();
>            //if thread gets here, it will print 1 due to
>            //correct construction (no leak of ref from consructor)
>            //and final field semantics.
>            //But if goodHolder volatile, f doesn't need to be
>            //final except to ensure that the value is not modified--special
>            //treatment in the memory model is not needed.

True also.

Hanson Char
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Hanson Char]

> Safe publication _is_ needed to ensure that thread2 will
> terminate, right?

Right.

>The point is that a data race on the reference to
> the published object is probably bad for reasons that may have nothing to
> do with the final fields, but that getting rid of that data race also
> eliminates the need for the special semantics for final fields for
> safely constructed objects.  This latter claim could be wrong--but
> if it is, I'd appreciate an explanation.

True in your code sample.  However, in general, safely constructed
objects with non-final fields are potentially subject to further
modification, and therefore potential data races.

As far as thread-safety is concerned, final fields are preferred over
non-final fields, whenever it is permissible.

Hanson Char
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest