Re: [Sablevm-developer] Threading support in SableVM

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

Archie Cobbs wrote:
> Chris Pickett wrote:
> 
>>As a side note, Etienne, it seems strange to me that under contention, 
>>you don't inflate the actual thin lock being released in your algorithm, 
>>but you inflate all of the other locks that the thread owns.  I think it 
>>means that if two threads were competing for just one lock, it would 
>>never get inflated.
> 
> 
> 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.

Hi Archie (and Etienne),

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? 
(because it's apparently likely to arise)  Or is there some reason why 
the inflation path is faster than the fat lock path?  That's what I 
still don't understand.  If you're telling me it simply doesn't make a 
difference, then fair enough.

Anyway, I suppose it's an experiment to try.

Something else that occurred to me: one of the supposed benefits of 
Bacon's/Onodera's/Etienne's thin lock algorithm is that you don't always 
require an atomic operation on unlocking.  But since we're introducing 
barriers now anyway, maybe a different algorithm altogether would be 
better, at least for multiprocessors.

So many details, so little time ... must ... not ... touch ... 
multiprocessor issues ... anymore.

Cheers,
Chris