[Insight-developers] Threading fixed. Really this time. Really. Really.

Fri, 05 Oct 2001 14:42:20 -0400

--=====================_94297773==_.ALT
Content-Type: text/plain; charset="us-ascii"

Hi Jim-

I didn't fully appreciate the extent of the mutex around the reference count to solve the threading problem. I looked at the code, and LightObject now has a pointer to a MutexLock (extra 4bytes) plus it does a new/delete on SimpleFastMutexLock every time it is constructed/deleted. The 4bytes are bad enough (things like itkCell are subclasses, and there may be a million of them), but the instantiation/destruction will really slow things down.

I'm going to think about this a bit, we should talk more next week.

Will

At 03:20 PM 10/4/2001 -0400, Miller, James V (CRD) wrote:
>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 
>
> 

--=====================_94297773==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hi Jim- 
 
I didn't fully appreciate the extent of the mutex around the reference
count to solve the threading problem. I looked at the code, and
LightObject now has a pointer to a MutexLock (extra 4bytes) plus it does
a new/delete on SimpleFastMutexLock every time it is constructed/deleted.
The 4bytes are bad enough (things like itkCell are subclasses, and there
may be a million of them), but the instantiation/destruction will really
slow things down. 
 
I'm going to think about this a bit, we should talk more next week. 
 
Will 
 
At 03:20 PM 10/4/2001 -0400, Miller, James V (CRD) wrote: 
<blockquote type=cite class=cite cite>I have fixed the
threading problem that Lydia reported a couple of weeks ago. 
&nbsp; 
Every threaded filter eventually calls GetInput() and
GetOutput() in its ThreadedGenerateData() method. These methods return
smart pointers to the appropriate DataObject subclass.&nbsp; The smart
pointer code calls Register() and UnRegister() on the appropriate
DataObjects. 
&nbsp; 
Unfortunately, Register() and UnRegister() are not thread
safe.&nbsp; 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.&nbsp; In other cases, the count was completely corrupted because
multiple writes to the same memory address occurred.&nbsp; The net result
was that data objects were deleted prematurely. 
&nbsp; 
I added a FastMutexLock to LightObject that protects the
reference count ivar.&nbsp; FastMutexLock has less overhead than
MutexLock on Windows systems and is equivalent to a MutexLock on other
systems.&nbsp; The mutex lock only protects the reference count ivar when
it is being modified.&nbsp; 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. 
&nbsp; 
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. 
&nbsp; 
(Side note: Will, the implementation of FastMutexLock is
incomplete.&nbsp; The methods New() and Delete() are declared but never
implemented.&nbsp; So currently I am using new/delete on the
FastMutexLock) 
 
Jim Miller 
 
_____________________________________ 
Visualization &amp; Computer Vision 
GE Corporate Research &amp; Development 
Bldg. KW, Room C218B 
P.O. Box 8, Schenectady NY 12301 
 
millerjv@crd.ge.com &lt;<a href="mailto:millerjv@crd.ge.com">mailto:millerjv@crd.ge.com</a>&gt; 
(518) 387-4005, Dial Comm: 8*833-4005, 
Cell: (518) 505-7065, Fax: (518) 387-6981 
 
&nbsp; 
</blockquote></html>

--=====================_94297773==_.ALT--