[Insight-developers] design issue

[Miller, James V (Research)]

If you have a std::vector of objects (as opposed to a std::vector
of pointer to objects), then the allocation of the objects 
will probably occur as a blind bulk allocation of a block 
of memory and then the constructor for each object is called
using the version of "new" where you provide an address to 
create the object at.  So there is probably only a single
mutex for the vector allocation.



-----Original Message-----
From: Joshua Cates [mailto:cates@poblano.sci.utah.edu]
Sent: Tuesday, April 16, 2002 2:22 PM
To: Miller, James V (Research)
Cc: Insight-Developers
Subject: RE: [Insight-developers] design issue


Hi Jim,

Thanks for the input.  I'll take a look at these articles.

>
> Can the LevelSetNode be a stacked based class? And hence not use
> SmartPointers at all? And hence avoid the mutexes?
>

We are not using smart pointers for the LevelSetNodes, but calling new and
delete has the same mutex problem (there is no way around this, right?).
I have considered using std::vector for the storage class of my object.
It has the advantage that different allocators could be used, i.e. a
non-threadsafe allocator could gain some speed if you know you don't need
thread safety.

Josh.

______________________________
 Josh Cates
 School of Computer Science
 University of Utah
 Email: cates@sci.utah.edu
 Phone: (801) 587-7697
 URL:   www.cs.utk.edu/~cates


On Tue, 16 Apr 2002, Miller, James V (Research) wrote:

> Here are my thoughts:
>
> Not knowing anything about your implementation or level sets....
>
> Can the LevelSetNode be a stacked based class? And hence not use
> SmartPointers at all? And hence avoid the mutexes?
>
> You could create an std::vector of LevelSetNodes for each thread.
>
> In the current issue of C/C++ Users Journal (May 2002), there are a
> number of articles on threading.  One article covers the boost thread
> library which looks pretty nice.  Other articles are on "thread local
> storage" (globals per thread). These are slower than real globals but
> faster than mutex code.
>
> Another article talks about different mechanisms for mutexes.  One
> interesting idea is a recursive mutex where a thread pays a penalty
> for the mutex the first time it grabs it. As long as it doesn't release
> the mutex, subsequent calls to get the mutex are fast.
>
> I'll be looking at these articles in a little more detail to see
> if there is anything we want to fold into ITK.
>
>
>
> -----Original Message-----
> From: Joshua Cates [mailto:cates@poblano.sci.utah.edu]
> Sent: Monday, April 15, 2002 2:41 PM
> To: Insight-Developers
> Subject: [Insight-developers] design issue
>
>
> Hi all,
>
> I'm soliciting feedback on a design issue.
>
> In our SparseFieldLevelSetImageFilter we manage lists of small data
> objects (call them LevelSetNodes).  These lists must grow and shrink
> dynamically. Because the filter is multithreaded, allocating and freeing
> LevelSetObjects as they are needed is not an option.  It's one of those
> cases where a naive implementation could actually be slower in a
> multithreaded environment because of mutex locks.
>
> So what we do is to pre-allocate a "store" of objects for each thread from
> which that thread borrows to grow its lists.  This allows us to operate in
> a distributed memory mode.  Each thread has a private reserve of memory
> that will not be touched by other threads, eliminating the need for mutex
> locks. Blocking only occurs when a thread runs out of memory and has to
> enlarge its store.  I am planning to encapsulate this functionality into
> an itk::DataObject subclass.
>
> Questions are these:
>
> Have other developers come up with different solutions to this same
> problem?
>
> If so, what memory management objects might already exist in Itk (or STL)
> to help?
>
> Would other developers find this "itkObjectStore" class useful?
>
> Josh.
>
>
>
> ______________________________
>  Josh Cates
>  School of Computer Science
>  University of Utah
>  Email: cates@cs.utah.edu
>  Phone: (801) 587-7697
>  URL:   www.cs.utk.edu/~cates
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>