Etienne M. Gagnon wrote:
> I do not agree. If I remeber correctly, this atomicity is only true
> of "volatile" variables. Otherwise, you have no garantee that the
> integer value visible to one thread is the same as the one visible to
> another on a multiprocessor system.
>
> Be careful with such "micro-optimizations" which can be based on false
> assumptions. Let the compilers/VM do these optimizations.
First - removing as much synchronization as possible, while staying
compatible is certainly a good thing. Synchronizing is _really_ costly -
I remember one of my small programs using java.util.Random to run 4
times faster after removing 'synchronized' from few methods in this
class. Of course this was uncompatible change, but if this could be done
in compatible way, it is a clear win.
As for the Hashtable size(). Is there any point where it matters ?
a) all the rest of Hashtable is synchronized where needed and will
access size correctly
b) code from outside has to synchronize on Hashtable externally anyway,
if you want to make complex operations. It is perfectly ok to have
//A
if ( !map.isEmpty() )
{
//B
System.out.println(map.entrySet().iterator().next());
}
throwing no such element. Having isEmpty synchronized would allow us to
catch changes made at point A, but not at point B. On the other hand, if
you manually synchronized entire block (as it should be done), then at
entry, A is propagated and at B no change can occur.
If you can show me an example, where having isEmpty()/size()
synchronized _guarantees_ anything with fully preemptive threading,
which is not guaranteed with unsynchronized version, then let it be your
way. But I think that no such example can be given (but I would be happy
to be proven wrong, as this would mean I do not understand some basic
stuff with java threading).
Artur
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
