THis is a little off-topic, but...
> There is no reason to synchronize access to the random number generator.
> It's Java code, so no safety properies can be violated with unsynchronized
> concurrent access. (Presumably no safety properties depend on the outcome
> of a random number generator.) If the code were not synchronized, the client
> could choose to use either per-thread random number generators, or to
> synchronize access to a global one. (The interface is otherwise nicely
> designed to make both possible. The actual benchmark uses the former
> model.) As it stands, reasonable performance for multithreaded simulations
> is needlessly excluded. Even if my compiler manages to eliminate the
> synchronizations, some other compiler waon't, thus effectively making the
> code unportable if I care about performance.
> General purpose libraries should almost always leave synchronization to the
> client, unless that violates some safety properties.
It's a very hard call here, and in fact it is almost always a very
hard call in Jave library code. You'd like to say that two invocations
of a random number generator produce independent results. Anyone can
understand this. It is a very nice property. It eliminates the
possiblility of serious but subtle application programming errors. But
maintaining it requires synch, to avoid two calls using same internal
state. On the other hand, I've lost count of you many times I've taken
the java.util.Random class and hacked it into class NoSynchRandom by
stripping out the synch to eliminate needless slowdowns. Perhaps a
better solution might have been to offer two versions in the library,
with a clear name like NoSynchRandom for the unsafe one so no one
would choose it by mistake.
(Further digressing, random number generators using CAS for state
updates might also be a good compromise. You cannot implement this in
Java today though. Also the wordsize limits of CAS would be tricky to
overcome in some RNGs.)
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