[K42-discussion] race condition in clustered object call on unoptimized build

[Bryan S Rosenburg]

You've missed my point.  We want every "DREF(ref)" to dereference ref 
exactly once.  The problem that's been reported is that the compiler is 
dereferencing ref more than once for a single DREF instance.  Burying the 
dereference in a volatile asm would keep the compiler from doing that.

- Bryan




Michal Ostrowski <mostrows at watson.ibm.com> 
02/10/2006 06:48 PM

To
Bryan S Rosenburg/Watson/IBM at IBMUS
cc
k42-discussion at ozlabs.org
Subject
Re: [K42-discussion] race condition in clustered object call on 
unoptimized build






Actually, an inline volatile asm would cause it to be evaluated every
time. You could use this to force the de-ref sequence to restart from
scratch on every reference, and would make the intermediate result
invisible to the compiler for optimization.

Michal



On Fri, 2006-02-10 at 17:30 -0500, Bryan S Rosenburg wrote:
> 
> I'm really surprised that code generated for "DREF(ref)" would
> evaluate (*ref) more than once, even in unoptimized code.  (*ref) is
> an expression that results in a pointer to an object, and you're
> saying that in invoking a method on the resulting pointer, the
> compiler evaluates the expression twice.  I have to take your word for
> it, but as I said, I'm really surprised. 
> 
> The good news is that it can probably be fixed in the DREF macro
> itself, maybe (as suggested by Michal) by putting the evaluation of
> (*ref) in an inline volatile asm, which the compiler wouldn't dare
> evaluate twice. 
> 
> Good catch! 
> 
> - Bryan 
> 
> 
> 
> Raymond Fingas
> <fingas at eecg.toronto.edu> 
> Sent by:
> k42-discussion-bounces at ozlabs.org 
> 
> 02/10/2006 04:54 PM 
> 
> 
>                To
> k42-discussion at ozlabs.org 
>                cc
> 
>           Subject
> Re:
> [K42-discussion]
> race condition in
> clustered object
> call on
> unoptimized build
> 
> 
> 
> 
> 
> 
> 
> 
> Well, changing from a real object to a default object (or vice
> versa...)
> is supposed to be a valid thing to do, even if one or more threads are
> running. So that isn't really an option. I'm not sure it's a serious
> problem, though, since the odds of hitting the race are low, there is
> an
> easy workaround (an optimized build such as partDeb or noDeb), and
> there
> is an obvious proper solution (modify the clustered object calling
> algorithm to avoid multiple reads of the LTT). The proper solution may
> well be possible by modifying the DREF macro, or it may require
> modifying
> the compiler (ouch!). At least that is my thought... It's definitely a
> bug
> in K42, though, and in one of the well tested and expected to work
> places.
> 
> Here is an example of the problem that should be easy to understand.
> Consider threads A and B, both running on the same VP. A is trying to
> call
> a clustered object when it is interrupted by B, which calls the same
> clustered object:
> 
> A
> B
> DREF(co)->foo()
> r11=*co                                  (ltt)
> r11=*r11                 (this)
> r11=112(*r11)                 (f'n pointer)
> mtctr r11
> 
> DREF(co)->foo()
> 
> r11=*co                                  (ltt)
> 
> r11=*r11                 (this)
> 
> r11=112(*r11)                 (f'n pointer)
> 
> mtctr r11
> 
> r11=*co                                  (ltt)
> 
> r3=*r11                                  (this)
> 
> bctrl
> (calls default object and installs local representative)
> r11=*co                                  (ltt)
> r3=*r11                                  (this)
> bctrl
> (calls default object with local representative this pointer)
> 
> On Thu, 9 Feb 2006, Dilma DaSilva wrote:
> 
> >
> > This sounds like a nasty race condition.
> >
> > Could we mark the entry on the LTT is invalid when changing it from
> a
> > real object to the default one, and only reuse entries after the
> > generation count indicates that no "old thread" could be in the
> midst
> > of checking?
> >
> > I'm probably missing something ... I wish I could jump into this now
> > :-)
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion
> 
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20060212/98662ea4/attachment.htm