[Insight-developers] Multi-threading strategies

[Torsten Rohlfing]

Hi --

I think you need to consider also that there's a cost to suspending and 
re-activating a thread. Do you know how you're going to do it? I assume 
a condition variable or something?

 From my personal experience, I can say that I considered this option 
once over creating new threads, and I tried it to some extent, but it 
did not lead to any tangible benefit using pthreads on Linux. Basically, 
the cost of using the condition variable with the added complexity of 
the implementation completely eliminated any benefit from avoiding 
thread creation and joining. There may of course be differences 
depending on your platform and the efficiency of its threads implementation.

Which certainly still leaves the one advantage that by keeping threads 
around you avoid those incredibly annoying thread creation/annihilation 
messages in gdb ;)

Cheers!
  Torsten

> That is definitely the preferred method...go for it! :)
>
> Stephen
>
> Blezek, Daniel J (GE, Research) wrote:
> >/ Hi all,
> />/ 
> />/   I was debugging a multi-threaded registration metric today, and gdb 
> />/ nicely prints thread creation/destruction messages.  In our current 
> />/ MultiThreader, pthreads are created/joined in the scatter/gather 
> />/ pattern.  For a general filter, this isn't likely to be a problem, 
> />/ 'cause it executes only once (in general).  For optimization metrics, it 
> />/ may be called thousands of times, leading to a huge number of pthreads 
> />/ created/joined.  Is this efficient?  Would it be worth while to 
> />/ investigate keeping threads around, rather than joining them?  They 
> />/ could simply sit idle until they have something to do...  This would 
> />/ reduce overhead, but may add complexity, but we only need to get it 
> />/ right once...
> />/ 
> />/   Stephen Aylward: any comments?
> />/ /

-- 
Torsten Rohlfing, PhD          SRI International, Neuroscience Program
 Research Scientist             333 Ravenswood Ave, Menlo Park, CA 94025
  Phone: ++1 (650) 859-3379      Fax: ++1 (650) 859-2743
   torsten at synapse.sri.com        http://www.stanford.edu/~rohlfing/

     "Though this be madness, yet there is a method in't"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: torsten.vcf
Type: text/x-vcard
Size: 366 bytes
Desc: not available
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20070728/50562aea/torsten.vcf