[Insight-developers] design issue

[Miller, James V (Research)]

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