[Insight-developers] design issue

[Joshua Cates]

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
>