[OpenJDK 2D-Dev] Thread-Private RenderBuffers for RenderQueue?

Dmitri Trembovetski Dmitri.Trembovetski at Sun.COM
Mon Mar 24 16:44:51 UTC 2008

   Hi Clemens,

Clemens Eisserer wrote:
> Hello,
> 1.) While studying RenderQueue from the STR based 2d pipelines I
> notices synchronization happening for every command put in the queue.
> I don't know wether tuning this is worth anything (guess not), but are
> there cases which make thread-private RenderBuffers impossible (maybe
> with a limit of buffers allocated)? Many threads rendering to the same
> surface don't have any guarantees anyway when an operation is
> performed. Or is ReentrantLock so fast that it really does not make
> any sence worriyng about?

   Since most applications do render from one thread (either the
   Event Queue like Swing apps, or some kind of dedicated rendering
   thread like games), the lock is indeed very fast, given
   biased locking and such.

   I would suggest not trying to optimize things - especially tricky
   ones which involve locking - until you have
   identified with some kind of tool that there's a problem.

> 2.) I have JDK7b19, I am not completly sure wether the sync()-method
> is 100% thread-safe, or wether this is ok in that case.
> The field "theInstance" is written to in a synchronized-block (in
> getInstance())  but in sync() its accassed without synchronization. It
> may appear null (as far as I understand) in one thread while another
> has already set it. Don't know wether this could be a problem?

   If it appears null during a sync() call, no harm is done (the
   sync is just ignored - which is fine given that the render queue
   hasn't been created yet, so there's nothing to sync), so this is
   not a problem.


More information about the 2d-dev mailing list