Cliff Click wrote:
> 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.
There might not be a guarantee in the sense of the Java platform but on a
given VM with native threads and a multiprocessor and nothing else hogging
CPU's then it will get a chance to run more often than it won't. So maybe as
I already require some intimacy with the VM's behaviour requiring some more
is not such a bad thing. *BUT* I don't think there is any suggestion that VM
implementors will document these sort of things.
> 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! :-) :-) :-)
It is only "broken" in a performance sense. With untampered read/write locks
on a large N-way MP system my application (this is theoretical I don't
actually have such an app - though may be Volano would qualify) shows
excellent performance characteristics - throughput, response time etc. With
this lock merging "optimisation" I no longer have read/write locks and my
performance slumps by a factor of N.
> 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
Can you elaborate on this broad class? Are these really MT apps or apps with
unnecessary sync? Just curious whether removing unneccesary sync would
render the current optimisation unnecessary?
Let's hope the "big apps" don't suffer - or maybe there's a switch to turn
off this "feature" ;-)
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