On second thought, I would be very bothered by the kind of fusing in David's
example.
While it would be nice if the runtime compiler could automatically remove
all the unnecessary synchronization in the Java API and elsewhere, it would
be much worse if it messed with the pattern of higher-level locks that I so
carefully and skillfully designed for my application :-)
I don't see how a compiler can win at this game.
Before I completely switch teams, though, I should first ask: How much
fusing is already happening today?
----- Original Message -----
From: "David Holmes" <dholmes@dstc.edu.au>
Sent: Sunday, February 04, 2001 6:49 PM
> I think we all agree that merging synch blocks is always
> legal with respect to our new proposed memory model.
I most certainly do not agree! [ ... ]
Consider a simple example - using a read/write lock to allow
concurrent reads of a shared data structure for searching:
rw.acquireReadLock();
// lengthy search code
rw.releaseReadLock();
----- Original Message -----
From: "Joseph Bowbeer" <jozart@csi.com>
Sent: Friday, February 02, 2001 10:13 PM
Concerning loop unrolling: permitting some number of fused
unrollings woudn't bother me. In my experience, if a looping
worker thread is sharing a lock with a GUI event thread, then
a yield or sleep (or scheduler) is needed to prevent the worker
from interfering with the responsiveness of the GUI.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT