Design for shared data
 

Group,
I have a design a multi-threaded system that uses good amount of shared
data. This data is needed in multiple classes/functions. I have three
designs for it.
1. Keep the data global, so that it can be accessed any where
2. Wrap the data in singleton class and use it wherever needed by
getInstance static method.
3. Pass the data by constant reference where ever needed. In this case
if function is part of some function hierarchy then data will have to be
passed from topmost function to the function where it is used.

All these approaches will solve the issue. I am not able to see
advantages or disadvantages of these approaches. Any new approach is
also welcome.

Please consider the solution form the point of view of synchronization
effort, since shared data is to be used in multi-threaded solution.
thanks
ittium

Re: Design for shared data
 

On 2011-9-25 14:47, ittium wrote:
> Group,
> I have a design a multi-threaded system that uses good amount of shared
> data. This data is needed in multiple classes/functions. I have three
> designs for it.
> 1. Keep the data global, so that it can be accessed any where
> 2. Wrap the data in singleton class and use it wherever needed by
> getInstance static method.
> 3. Pass the data by constant reference where ever needed. In this case
> if function is part of some function hierarchy then data will have to be
> passed from topmost function to the function where it is used.


Singletons are evil
http://blogs.msdn.com/b/scottdensmor...25/140827.aspx

And they are more evil in multiple thread.

So your 1 and 2 approached are kicked out.

And 3 is the good approach, IMO.


--
WQ

Re: Design for shared data
 

On 25.09.11 10.45, Qi wrote:
> On 2011-9-25 14:47, ittium wrote:
>> Group,
>> I have a design a multi-threaded system that uses good amount of shared
>> data. This data is needed in multiple classes/functions. I have three
>> designs for it.
>> 1. Keep the data global, so that it can be accessed any where
>> 2. Wrap the data in singleton class and use it wherever needed by
>> getInstance static method.
>> 3. Pass the data by constant reference where ever needed. In this case
>> if function is part of some function hierarchy then data will have to be
>> passed from topmost function to the function where it is used.
>
>
> Singletons are evil
> http://blogs.msdn.com/b/scottdensmor...25/140827.aspx

Well, the alternative, dependency injection, becomes evil to, if it has
to be applied multiple times to the same classes for a dozen different
global services. It even might blow up the memory footprint of your
application it DI has to be applied to many objects, unless you pass the
reference to the global singleton as template parameter. So it depends.

> And they are more evil in multiple thread.

This makes no difference at all. You have to take care of thread safety
anyway.


Marcel

Re: Design for shared data
 

On 25-09-2011 PM 06:44, Marcel Müller wrote:
> On 25.09.11 10.45, Qi wrote:
>> On 2011-9-25 14:47, ittium wrote:
>>> Group,
>>> I have a design a multi-threaded system that uses good amount of shared
>>> data. This data is needed in multiple classes/functions. I have three
>>> designs for it.
>>> 1. Keep the data global, so that it can be accessed any where
>>> 2. Wrap the data in singleton class and use it wherever needed by
>>> getInstance static method.
>>> 3. Pass the data by constant reference where ever needed. In this case
>>> if function is part of some function hierarchy then data will have to be
>>> passed from topmost function to the function where it is used.
>>
>>
>> Singletons are evil
>> http://blogs.msdn.com/b/scottdensmor...25/140827.aspx
>
> Well, the alternative, dependency injection, becomes evil to, if it has
> to be applied multiple times to the same classes for a dozen different
> global services. It even might blow up the memory footprint of your
> application it DI has to be applied to many objects, unless you pass the
> reference to the global singleton as template parameter. So it depends.
>
Assuming that dependencies are mutable and so are always passed by
reference, dependency injection will blow up the memory footprint, if
you assume that most of the class will have large number of dependencies.

From the discussion here and some googling, it appears DI with factory
pattern seems to me as a good idea for average cases. I favor factory
pattern so that dependency instance searching can be centralized.