My design goal was "doesn't corrupt anything if run from multiple
threads" (in other words don't require synchronization in any common
places just to keep it functional and don't require it to be used from a
particular thread), but only correct behavior if run from 1 thread at a
time.
In other words, it can be used by multiple threads in sequence, but not
simultaneously.
...jim
Roman Kennke wrote:
Hi there,
first of all, let me say that - especially in the light of this thread,
I support Mario's change (removal of this one line from the constructor)
for the following reasons:
- It should not be necessary as you say, this field should always be
initialized before use by validatePipe().
- If it's not, it's most likely a bug.
- Therefore this line is only good for hiding bugs.
One thing is not quite clear to me:
- A race condition where thread A is validating the pipeline and
installs the pipeline objects but hasn't yet reached the code to
install the loops while thread B starts rendering using that SG2D thus
invoking an operation on a partially initialized pipeline - in this
case the NPE is appropriate and allowed since we don't support
multi-threaded use of the Graphics2D objects.
I was always under the assumption, that Java2D should be thread safe.
And in many places we make sure it is, e.g. in the SurfaceData objects.
But now you say, it isn't. So what is the real thing about Java2D and
thread safety. Is it only supposed to be thread safe when each thread
gets its own Graphics2D object? I think I remember back in the GNU
Classpath days we had a test case that shared a Graphics (no Graphics2D
back then..) object between threads and was supposed to be ok, but I
might be wrong here... Can you enlighten me what is the situation w/
Java2D and thread safety?
/ Roman
