[concurrency-interest] [Javamemorymodel-discussion] Fences.keepAlive

Joe Bowbeer joe.bowbeer at gmail.com
Wed Jan 21 16:55:33 EST 2009

More related to keepAlive:

1. Names

 I think one of the "until" names better conveys what it is trying to do.


Though I would be even more comfortable if a Runnable were used to define
the scope:

  doWithStronglyReachableReference(ref, runnable);

Is that possible?  Or is there a chicken-egg problem?

2. Typo in keepAlive example:

  keepAlive(this) => Fences.keepAlive(this)

3. Concerning "strongly reachable" in the method description, should this
link to "reachability" instead:



PS - Regarding "alive," I reiterate my suggestion to use a term that is
defined in the referenced sections of the JLS. That statement that "live"
includes things that are not "live" still freaks me out.

On Wed, Jan 21, 2009 at 8:39 AM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> I *can* follow the class description and its Fences examples.
> I don't follow keepAlive.  It's barely covered in the class description and
> the method description doesn't make sense to me.
> More on fences and keepAlive below.
> Fences.  [More yowing...]
> It's hard for me to mesh fences with the JMM.  In the context of JMM,
> fences seem like magic.  (Whereas in the magical world of a DEC Alpha,
> fences impose reality.)
> Do fences create open-ended happens-before edges?  Or are the edges only
> created when the next load or store occurs?  Or does it matter?
> More to the point: Are there Java code transformations (e.g., injections)
> that could be used to illustrate what they really do in terms of Java code?
> Are fences actually cheap to implement on all platforms?  Won't there be
> some platforms where they are more expensive than current alternatives?  (If
> not, why wasn't the JMM spec'd in terms of fences?)
> keepAlive.
> I don't think this is covered well-enough in the class description, and I
> can't follow the example in the method description.  I also wonder if
> there's a better name.
> Some problems I encountered:
> I was expecting the "Reference" link to define the term "strongly
> reachable", but neither "strong" nor "reachable" can be found on that page.
> What does "alive" mean?
> JLS 12.6.1 defines the reachable and finalized attributes, but it never
> adequately defines "alive".
> While there is mention of keeping a thread alive, and of live references,
> these terms seem to be used intuitively, and sometimes confusingly, for
> example:
>     "... then there can never be any live references to it (this includes
> references that are not live, but might be resurrected by finalizers) ..."
> The undead is really alive?  What does alive mean?  Is it some combination
> of reachable and finalized attributes?
> I suggest giving keepAlive a more verbose name, like the other fence
> method.  Preferably a name composed of terms that are defined in the JLS.
> (I also recommend considering tightening up the use of the terms "live" and
> "alive" in the JLS.)
> keepNotFinalized?
> Though even with a new name, I suspect I'll still be trying to figure out
> what this does...
> Joe
> On Wed, Jan 21, 2009 at 5:41 AM, Doug Lea wrote:
>> Boehm, Hans wrote:
>> > I'd be inclined to somewhat simplify the example, and not use the
>> > constructor.  I'm also not sure I'd mention the word "native", since
>> that
>> > seems to mislead people to believe that this is a native code issue.
>> Thanks! Added with a few minor edits.
>> Plus a few other minor edits elsewhere.
>> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/Fences.html
>> -Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090121/8983f943/attachment.html>

More information about the Concurrency-interest mailing list