Re: [Sablevm-developer] Threading support in SableVM

[Chris P. <chr...@ma...>]

Archie Cobbs wrote:
> Chris Pickett wrote:
> 
>>>The inflating of the "other" locks is to avoid this inefficiency.
>>>But it's not necessary to do this for threads waiting on the actual
>>>lock being released, because you do indeed want those thread to
>>>wake up.
>>
>>I understand and agree with most if not all of that, certainly 
>>pertaining to the other locks.  I guess I was wondering, wouldn't things 
>>be *faster* if you inflated the actual released thin lock, because you 
>>wouldn't have to take the (what I assumed/am assuming to be slow) 
>>inflation path for that lock again when future contention arose? 
> 
> 
> A lock can only be inflated once. So it's never slower to delay this
> inflation to a later point.

(not CCing anyone -- the list seems fairly stable these days -- please 
let me know if you want to be CC'd Archie, Etienne -- will ask Clark to 
subscribe to the list)

I tried it, and have a test case where it's faster for me to inflate 
than not (attached).

with inflation:

real    2m31.746s
user    2m13.740s
sys     0m58.580s

without inflation:

real    2m39.046s
user    2m51.030s
sys     0m57.200s

That's with the extra atomic operations on an MP system (timing 
information is screwed up, but I think it's safe to say that it's still 
faster).

If I remove the barriers, and use the MP system again ...

with inflation

real    2m10.773s
user    2m0.070s
sys     0m33.280s

without inflation

real    2m41.173s
user    2m51.180s
sys     0m57.890s

which actually surprised me!

I don't really want to investigate this further right now, determine if 
it affects real-world multithreaded benchmarks, try it on uniprocessors, 
etc. etc., but I don't think we can categorically say that not inflating 
is always faster.  In fact, I think that as a unit, the inflation path 
is slower than the fat lock path (and by not inflating we continually 
take the inflation path).

At the same time, I think *deflation* could be a nice win, and Onodera's 
original algorithm actually supports this.

Cheers,
Chris