[Insight-developers] ThreadedGenerateData and Factories
Miller, James V (Research)
millerjv at crd . ge . com
Thu, 29 Aug 2002 17:19:47 -0400
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C24FA1.CD5B6554
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C24FA1.CD5B6554"
------_=_NextPart_001_01C24FA1.CD5B6554
Content-Type: text/plain;
charset="iso-8859-1"
Just spent the last day tracking down an intermittent problem with a new filter when run on a machine
with 12 processors.
My test would crash in an IO factory whenever an IO factory was used after my filter executed. Turns
out
that my filter was calling New() on an ITK object inside the ThreadedGenerateData routine. After
this
call to New(), the standard factory mechanism was hosed. I fixed my particular problem by moving the
call to New() to the BeforeThreadedGenerateData method.
I think there is something in the Factory mechanism that gets polluted when multiple threads try to
instantiate objects. Note that there were no factories that could create the objects I was creating
in the
threads. But the next time I needed to create an object using the factory mechanism, my program
would crash.
I believe the way the New() works is that all registered factories are given an opportunity to try to
create
every object instantiated with New(). There is a static list of registered factories that is built
(and rebuilt?)
during the object instantiation phase. It "feels" like when multiple threads are trying to create
something
with New(), this static list of factories gets corrupted.
In general, there can be problems allocating memory in multiple threads. I don't think malloc is
guarenteed to be thread safe. However it could do a "int *i = new int[100000]" inside a thread
without a problem but could not
do an "Image<float,2>::New()" without crashing.
Jim Miller
_____________________________________
Visualization & Computer Vision
GE Research
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301
millerjv@research.ge.com <mailto:millerjv@research.ge.com>
james.miller@research.ge.com
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
------_=_NextPart_001_01C24FA1.CD5B6554
Content-Type: text/html;
charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2715.400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=874524820-29082002><FONT size=2>Just spent the last day
tracking down an intermittent problem with a new filter when run on a machine
with 12 processors.</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>My test would crash in an IO
factory whenever an IO factory was used after my filter executed.
Turns out </FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>that my filter was calling
New() on an ITK object inside the ThreadedGenerateData routine. After
this</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>call to New(), the standard
factory mechanism was hosed. I fixed my particular problem by moving
the</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>call to New() to the
BeforeThreadedGenerateData method. </FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>I think there is something in
the Factory mechanism that gets polluted when multiple threads try to
</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>instantiate objects. Note
that there were no factories that could create the objects I was creating in the
</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>threads. But the next
time I needed to create an object using the factory mechanism, my program
</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>would
crash.</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>I believe the way the New()
works is that all registered factories are given an opportunity to try to
create</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>every object instantiated with
New(). There is a static list of registered factories that is built
(and rebuilt?)</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>during the object instantiation
phase. It "feels" like when multiple threads are trying to create
something </FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>with New(), this static list of
factories gets corrupted.</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>In general, there can be
problems allocating memory in multiple threads. I don't think malloc is
guarenteed to be thread safe. However it could do a "int *i = new
int[100000]" inside a thread without a problem but could not</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2>do an
"Image<float,2>::New()" without crashing.</FONT></SPAN></DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=874524820-29082002><FONT size=2></FONT></SPAN> </DIV>
<DIV class=Section1>
<P style="MARGIN: 0in 0in 0pt"><B><SPAN
style="COLOR: navy; FONT-FAMILY: 'Comic Sans MS'">Jim Miller</SPAN></B>
<BR><B><I><SPAN
style="FONT-SIZE: 10pt; COLOR: red; FONT-FAMILY: Arial">_____________________________________</SPAN></I></B><BR><EM><SPAN
style="FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">Visualization &
Computer Vision</SPAN></EM><I><SPAN
style="FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial"><BR><EM>GE
Research</EM><BR><EM>Bldg. KW, Room C218B</EM><BR><EM>P.O. Box 8, Schenectady NY
12301</EM><BR><BR></SPAN></I><EM><U><SPAN
style="FONT-SIZE: 7.5pt; COLOR: blue"><A
href="mailto:millerjv@research.ge.com">millerjv@research.ge.com</A></SPAN></U></EM></P>
<P style="MARGIN: 0in 0in 0pt"><EM><U><SPAN
style="FONT-SIZE: 7.5pt; COLOR: blue">james.miller@research.ge.com</SPAN></U></EM><BR><I><SPAN
style="FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">(518) 387-4005, Dial
Comm: 8*833-4005, </SPAN></I><BR><I><SPAN
style="FONT-SIZE: 7.5pt; COLOR: black; FONT-FAMILY: Arial">Cell: (518) 505-7065,
Fax: (518) 387-6981</SPAN></I> </P>
<P class=MsoNormal> <?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></P></DIV>
<DIV> </DIV></BODY></HTML>
------_=_NextPart_001_01C24FA1.CD5B6554--
------_=_NextPart_000_01C24FA1.CD5B6554
Content-Type: application/octet-stream;
name="James Miller (E-mail).vcf"
Content-Disposition: attachment;
filename="James Miller (E-mail).vcf"
BEGIN:VCARD
VERSION:2.1
N:Miller;James
FN:James Miller (E-mail)
ORG:GE Reseach;Imaging Technologies
TEL;WORK;VOICE:(518) 387-4005
TEL;WORK;VOICE:*833-4005
TEL;CELL;VOICE:(518) 505-7065
TEL;WORK;FAX:(518) 387-6981
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Visualization and Computer Vision;BLDG KW, RM C218B=0D=0APO Box 8;Schenecta=
dy;NY;12301;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Visualization and Computer Vision=0D=0ABLDG KW, RM C218B=0D=0APO Box 8=0D=
=0ASchenectady, NY 12301=0D=0AUnited States of America
EMAIL;PREF;INTERNET:millerjv@research.ge.com
REV:20020405T145025Z
END:VCARD
------_=_NextPart_000_01C24FA1.CD5B6554--