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.
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.
Remind me again *why* we are letting this happen? :)
Cheers,
David
-------------------------------
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