[Insight-developers] Threading fixed. Really this time. Really. Really.
Miller, James V (CRD)
millerjv@crd.ge.com
Thu, 4 Oct 2001 15:20:41 -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_01C14D09.A82F96A0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C14D09.A82F96A0"
------_=_NextPart_001_01C14D09.A82F96A0
Content-Type: text/plain;
charset="iso-8859-1"
I have fixed the threading problem that Lydia reported a couple of weeks ago.
Every threaded filter eventually calls GetInput() and GetOutput() in its ThreadedGenerateData()
method. These methods return smart pointers to the appropriate DataObject subclass. The smart
pointer code calls Register() and UnRegister() on the appropriate DataObjects.
Unfortunately, Register() and UnRegister() are not thread safe. So multiple threads were
incrementing and decrementing the reference count at the same time. So the reference count on inputs
and outputs were being corrupted. In some case, a thread might not have successfully incremented the
reference count but successfully decremented it. In other cases, the count was completely corrupted
because multiple writes to the same memory address occurred. The net result was that data objects
were deleted prematurely.
I added a FastMutexLock to LightObject that protects the reference count ivar. FastMutexLock has
less overhead than MutexLock on Windows systems and is equivalent to a MutexLock on other systems.
The mutex lock only protects the reference count ivar when it is being modified. The implementation
is not quite right when the reference count goes to zero. There could be a race condition to delete
the object when the reference count finally goes to zero.
I have run my test case 100,000 times and the test has not failed. Earlier today is was failing a
couple times every 1000 runs.
(Side note: Will, the implementation of FastMutexLock is incomplete. The methods New() and Delete()
are declared but never implemented. So currently I am using new/delete on the FastMutexLock)
Jim Miller
_____________________________________
Visualization & Computer Vision
GE Corporate Research & Development
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301
millerjv@crd.ge.com < mailto:millerjv@crd.ge.com <mailto:millerjv@crd.ge.com> >
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981
------_=_NextPart_001_01C14D09.A82F96A0
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 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=954215918-04102001><FONT size=2>I have fixed the threading
problem that Lydia reported a couple of weeks ago.</FONT></SPAN></DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2>Every threaded filter
eventually calls GetInput() and GetOutput() in its ThreadedGenerateData()
method. These methods return smart pointers to the appropriate DataObject
subclass. The smart pointer code calls Register() and UnRegister() on the
appropriate DataObjects.</FONT></SPAN></DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2>Unfortunately, Register() and
UnRegister() are not thread safe. So multiple threads were incrementing
and decrementing the reference count at the same time. So the reference count on
inputs and outputs were being corrupted. In some case, a thread might not have
successfully incremented the reference count but successfully decremented
it. In other cases, the count was completely corrupted because multiple
writes to the same memory address occurred. The net result was that data
objects were deleted prematurely.</FONT></SPAN></DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2>I added a FastMutexLock to
LightObject that protects the reference count ivar. FastMutexLock has less
overhead than MutexLock on Windows systems and is equivalent to a MutexLock on
other systems. The mutex lock only protects the reference count ivar when
it is being modified. The implementation is not quite right when the
reference count goes to zero. There could be a race condition to delete the
object when the reference count finally goes to zero.</FONT></SPAN></DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2>I have run my test case 100,000
times and the test has not failed. Earlier today is was failing a couple times
every 1000 runs.</FONT></SPAN></DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=954215918-04102001><FONT size=2>(Side note: Will, the
implementation of FastMutexLock is incomplete. The methods New() and
Delete() are declared but never implemented. So currently I am using
new/delete on the FastMutexLock)</FONT></SPAN></DIV>
<DIV><BR></DIV>
<P><B><FONT face="Comic Sans MS" color=#000080>Jim Miller</FONT></B>
<BR><B><I><FONT face=Arial color=#ff0000
size=2>_____________________________________</FONT></I></B><I></I><BR><I></I><I><FONT
face=Arial color=#000000 size=1>Visualization & Computer Vision<BR>GE
Corporate Research & Development<BR>Bldg. KW, Room C218B<BR>P.O. Box 8,
Schenectady NY 12301<BR><BR></FONT><U><FONT face=Arial color=#0000ff
size=1>millerjv@crd.ge.com <<A
href="mailto:millerjv@crd.ge.com">mailto:millerjv@crd.ge.com</A>></FONT></U></I><BR><I><FONT
face=Arial color=#000000 size=1>(518) 387-4005, Dial Comm: 8*833-4005,
</FONT></I><BR><I><FONT face=Arial color=#000000 size=1>Cell: (518) 505-7065,
Fax: (518) 387-6981</FONT></I> </P><BR>
<DIV> </DIV></BODY></HTML>
------_=_NextPart_001_01C14D09.A82F96A0--
------_=_NextPart_000_01C14D09.A82F96A0
Content-Type: application/octet-stream;
name="Miller, James V (CRD).vcf"
Content-Disposition: attachment;
filename="Miller, James V (CRD).vcf"
BEGIN:VCARD
VERSION:2.1
N:Miller;James
FN:Miller, James V (CRD)
ORG:CRD;ESL
TITLE:Computer Scientist
TEL;WORK;VOICE:*833-4005
TEL;WORK;VOICE:1 518 387-4005
ADR;WORK:;KW-C218B;P.O. Box 8;Schenectady;New York;12301;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KW-C218B=0D=0AP.O. Box 8=0D=0ASchenectady, New York 12301=0D=0AUSA
EMAIL;PREF;INTERNET:millerjv@crd.ge.com
REV:20010420T140329Z
END:VCARD
------_=_NextPart_000_01C14D09.A82F96A0--