Re: Class Constants - pros and cons
On Thu, 29 Jul 2010, Lew wrote:
Tom McGlynn wrote:
But I'm not trying to persuade people that using flyweights in the
sense that I suggested in my example is necessarily the right thing to
do in all circumstances, merely to note that it may be a rational or
even desirable approach in some. That example was given to give a
concrete realization of an object that simultaneously implemented
flyweight and singleton, not for its intrinsic merit but I was a little
bemused by reaction to it.
When dealing with 200 M stars, one might be tempted to use a
multi-threaded approach. Sharing a singleton among threads introduces
the complexity and overhead of synchronization.
McGlynn's flyweights are immutable, so sharing them between threads should
be fine.
The mutable state lives in the parallel arrays, and access to those would
need to be controlled. *That* could be tricky, because there's no natural
object to lock on if you want to access a given row. You certainly can't
do it with a flyweight, because the same flyweight instance will be in use
by other threads to represent entirely different stars!
The straightforward object approach, combined with appropriate caching
(the buffer approach or DBMS approach) simplifies concurrent
implementations.
Hmm. I don't think Star-level locking would be a good idea, regardless of
how Stars work. You'd want to partition larger units between threads.
Given that you'll have to build a mechanism for controlling concurrency at
that level anyway, whether you have real stars or flyweights might not
matter very much.
tom
--
The art of medicine consists in amusing the patient while nature cures
the disease. -- Voltaire