--- David Holmes <dholmes@dltech.com.au> wrote:
> My problem with playing around with the contents of
> synchronized blocks may
> be more of an academic one than a practical one. But it seems
> to me that
> reasoning about the behaviour of programs is hard enough when
> you know what
> the code does, so reasoning about concurrent programs when
> what you see in
> the code is not what you get, becomes impossible. But if I'm
> the lone voice
> that thinks this is a problem, then perhaps its not a problem
> afterall.
>
> David
>
Looking back at an earlier example in this thread, while I can
see why this would worry people, I don't see this being much of
a problem.
The example was:
readlock.acquire();
// access data structure
readlock.release();
The concern was that the synchronization for acquiring and
releasing the the readlock would be merged into a single
synchronized block and the intent of the read lock would be
lost.
I don't worry about this because my assumption is that the
synchronized blocks will not be merged if the stuff in
// access data structure
is large.
I would expect a good JVM to only merge the synchronized blocks
when the following are true:
- the code between the synchronized blocks is not
significantly larger than the amount of code removed by merging
the synchronized blocks (if the code is significantly larger,
then merging the blocks won't be a significant optimization so
don't do it)
- the code between the synchronized blocks does not contain
loops whose bounds you can not reason about at compile time (or
class load time) and so cannot prove that the code is not
significantly larger than the locking code that will be
removed.
- the code between the synchronized blocks does not contain
blocking IO or other operations that can be unboundedly slow.
- the code between the synchronized blocks does not contain
anything else the JVM implementor knows to be slow enough on
machines their JVM will run on that the optimization would be
insignificant
This is a lot to trust the JVM implementor with, but I'm
trusting them with a million things anyway and at least a
thousand of those are just as subtle and critical to my
software working properly as this one. Some JVM somewhere will
blow this and eventually will get a bug reporton it--and other
JVMs will blow other things that turn out to matter to me and
they will get different bug reports.
A JVM implementor has a good chance of implementing this right.
Most JVMs will probably automatically optimize this correctly
many more times than the average developer will optimize this
correctly.
Now if someone was going to automatically remove code from
synchronization, I'd be much more nervous.
--Paul
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
-------------------------------
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