[Bug 92] threading is broken (most visible on SMP)

[email protected]
Newsgroups gmane.comp.java.vm.sablevm.bugs
Message-ID <[email protected]>
http://sablevm.org/bugs/show_bug.cgi?id=92





------- Additional Comments From [email protected]  2005-01-28 19:42 -------
Well, that was predictable (see last night's log below)! :)

I think the best way to solve these things FOR SURE is to use a tool like NuSMV
to model the locking algorithm and SMP memory behaviour and check that there are
no possible bad execution traces.

I even had the nerve to suggest this was a better project for gadek re: his VM
course than this execution trace / STEP stuff.

It's not a trivial undertaking, but I think it would be quite useful and
furthermore publishable (as a strong part of a larger work).  Formal
verification is designed to take care of problems like this, and I don't think
the problem space simulating two threads is so large as to be untractable.

http://nusmv.irst.itc.it/

I know, I know, I am supposedly "the SMP guy", but really, gadek has at this
point done more investigation into locking than I have and my hands are already
quite full with another project (spmt).  tofu (2P) and magic (4P) are available
at mcgill, although tofu is more so.

Chris

Jan 28 00:44:48 <gadek_>        so, can you authoritatively say whether we have
an improvement or not?
Jan 28 00:45:15 <cjfp>  no.
Jan 28 00:45:36 <cjfp>  it's only observationally better
Jan 28 00:45:57 <cjfp>  if you put a spin-lock in the locking algorithm
Jan 28 00:46:00 <cjfp>  that is bad
Jan 28 00:46:14 <cjfp>  and it's still not proven that this has eliminated problems
Jan 28 00:46:21 *       gadek_ slaps cjfp tenderly
Jan 28 00:46:41 <gadek_>        cjfp: you're going around my question :-) but
this gives me the answer already.
Jan 28 00:46:50 <cjfp>  well, it's dying less
Jan 28 00:46:57 <cjfp>  but there are also less NPE's
Jan 28 00:47:08 <gadek_>        no.  It has no assertion failures anymore.
Jan 28 00:47:20 <cjfp>  right, but there were very few in the first place
Jan 28 00:47:55 <gadek_>        lower no. of NPEs might be due to spinlocking
(giving time for cahces to get coherent etc)
Jan 28 00:48:22 <cjfp>  right
Jan 28 00:48:23 <cjfp>  so,
Jan 28 00:48:29 <cjfp>  observationally it's better
Jan 28 00:48:30 <gadek_>        Assertion failures in monitor code are *very*
bad. NPEs in classpath are completly another story.
Jan 28 00:48:48 <cjfp>  but i'm not sure that you really "eliminated" the
locking problem
Jan 28 00:48:58 <cjfp>  although possibly
Jan 28 00:49:09 <cjfp>  hence, i cannot say authoritatively
Jan 28 00:49:16 <cjfp>  i would ask egagnon
Jan 28 00:49:18 <gadek_>        I'd say: we have hopefully nailed down the
problem in SableVM, but the problem in classpath still remains.
Jan 28 00:49:31 <cjfp>  he won't like a spin-lock
Jan 28 00:49:39 <cjfp>  but if it works for now, fine
Jan 28 00:50:17 <gadek_>        cjfp: you probably should have a "read with
lock" or something to rread the lockword w/o caches.
Jan 28 00:50:45 <cjfp>  actually, maybe you did fix the problem
Jan 28 00:50:51 <cjfp>  i shouldn't rain on your parade
Jan 28 00:50:53 <cjfp>  good job!
Jan 28 00:50:56 <cjfp>  but still
Jan 28 00:50:59 <gadek_>        haha
Jan 28 00:51:05 <cjfp>  discuss with egagnon
Jan 28 00:52:00 <cjfp>  the whole point of his algorithm is to avoid spin-locks





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.