Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #606 > unrolled thread

Design for shared data

Back to article view | Back to comp.programming.threads

Contents

  Design for shared data ittium <ittium@gmail.com> - 2011-09-25 12:17 +0530
    Re: Design for shared data Qi <no@no.com> - 2011-09-25 16:45 +0800
      Re: Design for shared data Marcel Müller <news.5.maazl@spamgourmet.org> - 2011-09-25 15:14 +0200
        Re: Design for shared data ittium <ittium@gmail.com> - 2011-09-25 20:23 +0530
    Re: Design for shared data Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-25 06:05 -0500

#606 — 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

[toc] | [next] | [standalone]

#607

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/scottdensmore/archive/2004/05/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

[toc] | [prev] | [next] | [standalone]

#610

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/scottdensmore/archive/2004/05/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

[toc] | [prev] | [next] | [standalone]

#612

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/scottdensmore/archive/2004/05/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.

[toc] | [prev] | [next] | [standalone]

#608

ittium <ittium@gmail.com> wrote in news:j5miqi$mu6$1@dont-email.me:

> 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.

Or passed more implicitly as a member variable of the involved classes.

> 
> 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.

This very much depends on whether the data is mutable or immutable. If it 
is mutable, then in general both read and write access must be protected 
in multithreaded environment. This pretty much eliminates global 
variables (design 1), which are evil anyway.

Singletons are used if the logical scope of some data coincedes with the 
scope of process. I believe this happens quite rarely actually and most 
singletons are forced in the place  . Also, what happens if the program 
evolves over time and starts to require multiple data states coexisting 
in the same process? Therefore I would suggest design 3 as the most 
flexible. Initially the data can be kept in a singleton object, for 
example, and the reference to this singleton passed around, but later it 
would be easy to change this schema when needed.

You have not mentioned anything about performance requirements. Keeping a 
data in a single object might become a bottleneck when accessed from many 
threads. Typically such access would look like "lock a mutex, copy data 
to or from the singleton, release the lock". If there are N threads, this 
means that N-1 threads may be waiting for a single thread. If this is a 
problem or not depends on the frequency and duration of mutex locking, 
but the situation becomes worse all the time as more cpu cores appear in 
the processors. It might be better to make a copy of the shared data for 
each thread, which can be then accessed with no locking needed. If the 
data needs to be updated while the thread is running, then this can be 
organized by posting some events or messages in a queue which the thread 
is reading once in a while, for example.

Which approach is the best depends on the aplication and many other 
things, but your design 3 seems to be best in the sense that it can adapt 
itself to different solutions quite easily.

hth
Paavo

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web