Re: Important bug fix in current trunk

Hi Etienne,

Thanks (as always) for the detailed description.  I got your follow-up 
message with the solution.  Rearranging the SMP discussion to come 
first.  The quoting might be messed up.

Etienne Gagnon wrote:
> Hi Chris,
> 
> First...  The bug fix does nothing to fix SMP support; for that, the
> integration of atomic_ops and the implementation of the memory model JSR
> is needed.

 >>Also, please note, that if you are depending on an ordering between
 >>reads/writes in different threads, ...
 >
 >
 > I know all of this.  Did I ever claim that SableVM was safe to run on
 > SMP?

No...  I merely said that because I thought your problem might be 
related to bug 144, that's all.  From your description it does not sound 
very related.

 > Yet, I've heard between branches that you had started implementing
 > the memory model JSR.  Is there any chance you could contribute this
 > code within the upcoming months?  [Would be a retribution for me writing
 > this long and detailed reply to you. ;-P ]

All I have is some simple barrier functions.  I also have volatile / 
final support, but it is not so pretty (requires lots of duplicated 
instructions).

Anyway, I would like to contribute it, but before I contribute it I want 
to come up with test cases that demonstrate it actually does something. 
  So far, that has been difficult to show.  However, recently I came 
across a test case for Java volatile support that should die nicely, so 
I'll get that in there along with the GC/preparation bug test case.

I've turned into a firm believer of the "automated failing test case 
first, bugfix/implementation second, refactor third" development 
methodology...

>>...  Can you detail the unsafe
>>interleaving between threads that you discovered?  Can you explain
>>exactly how your solution fixes it and what happens if two threads
>>compete now?  I see the changes in prepare_code.c but I don't really see
>>the difference in execution semantics.
> 
> 
> Here's a quick description of the problem and its solution:

(I understood it all.)

As an alternative, is it possible to fix the problem by removing 
_svmf_periodic_check() from PREPARE_<X> and fixing the losing thread so 
that it updates its stack correctly?  It might be a smaller, more 
localized diff, plus you would save on an indirection.

I think this will fix quite a few of the "threading" bugs, so it will be 
important to go and test all of them again.  I'll look into it tomorrow.

Cheers,
Chris