Re: JavaMemoryModel: FWD: Question regarding nested synchronized blocks

From: Cliff Click (Cliff.Click@sun.com)
Date: Mon Apr 22 2002 - 23:21:47 EDT


David Holmes wrote:
> Cliff Click wrote:
>
>>Being possibly the first person to attempt this, here's how'd I
>>do it: I'd require that the stuff in comments:
>> " // access data structure"
>>be provable finite (better: short) duration.
>>Easy way to do this: don't coarsen the lock if there's a loop.
>
>
> The helps but I'm not comfortable with the ad-hoc formulation of the rule.
> It means that I don't know whether or not my read/write locking is going to
> get screwed up without knowing something about the VM internal policies.
>
>
>>This rules out:
>> BEFORE AFTER
>> for(...) { lock(X);
>> lock(X); for(...) {
>> ... ...
>> unlock(X) }
>> } unlock(X)
>>
>
>
> Glad to hear that. If I write the sync inside the loop rather than around it
> there is usually a good reason for that.
>
>
>>But does NOT rule out:
>> for( ...; i += 8 ) {
>> lock(X)
>> ...8 copies of loop body...
>> unlock(X)
>> }
>
>
> So if 8 is just 'n', for what value of 'n' does this screw up my
> synchronisation policy? And again how do I know what value of 'n' the VM
> will use.
There's only a chance (not a guarentee!) that another thread gets a
chance to run between the locks. I'm diddling with that chance.

What you are asking for is a more rigourous cost (one that justifies my
'8' or tells you what the ideal 'n' should be) - and a cost model goes way
way beyond anything we're trying to do here - or has been done in a
mainstream language.

> I'm very uncomfortable with a situation where the model says that the VM can
> completely break my code, but implementers tell me, don't worry we probably
> won't do that in practice. Just too ad-hoc for me.

If unroll-n-jam & coarsen breaks your code, then your code is broken
to begin with! Best discover it sooner, the sooner you can go about
fixing it! :-) :-) :-)

No offense intended: _I_ don't know how you can write interesting
policy codes without such a cost model. Yet this is not the time
or place to design a cost model.

> Remind me again *why* we are letting this happen? :)

Why are doing this? Because of interesting performance gains
on less delicate multi-threaded codes. There's a broad class
of codes for which this optimization is a pure win; the only
bugs exposed are ones which would show up someday on some other
platform.

> Cheers,
> David

Cliff

-- 
Dr. Cliff Click      Chief Architect, HotSpot Server  Sun Microsystems, Inc.
Cliff.Click@Sun.COM  Senior Staff Engineer            4150 Network Circle
(408) 276-7046       MS USCA14-102                    Santa Clara, CA 95054

------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT