Watch, Follow, &
Connect with Us
Public Report
Report From: Delphi-BCB/RTL/Delphi/Thread support    [ Add a report in this area ]  
Report #:  17712   Status: Closed
(Pulled) TThreadLocalCounter2 has a FLAW, see steps.  This causes major slow downs in custom variants which in turn slows down DB as it i
Project:  Delphi Build #:  5.0.5.63
Version:    6.0 Submitted By:   John Kaster
Report Type:  Crash / Data loss / Total failure Date Reported:  1/25/2002 12:00:00 AM
Severity:    Critical / Show Stopper Last Updated: 3/20/2012 2:24:39 AM
Platform:    All versions Internal Tracking #:   127203
Resolution: Fixed (Resolution Comments) Resolved in Build: : 10.0.2098.14501
Duplicate of:  None
Voting and Rating
Overall Rating: No Ratings Yet
0.00 out of 5
Total Votes: None
Description
TThreadLocalCounter2 has a FLAW, see steps.  This causes major slow downs in custom variants which in turn slows down DB as it is now very dependent on custom variants.
Steps to Reproduce:
Given the following code, where Foo is a TMultiYouKnowWhat

For I := 0 to 100000 do
Begin
   Foo.BeginRead;
   Try
      X := I;
   Finally
      Foo.EndRead;
   End;
End;

Each time the BeginRead occurs we do an TThreadLocalCounter2.Open.  Inside of there you have a spin loop that goes though the PThreadInfo2 single linked list.  It won't find the thread, for obvious reasons.  You then call Recycle, which won't find a free spot in the list.  So you then add to the list.  Thus the list gets longer each time a BeginRead happens.  Recycle won't find a free spot because Delete only clears the ThreadID field, BUT not the Active field.  Recycle keys off of that.  Doing "Active := not Alive" (for lack of any other good value) in the Delete seems to work like a champ but I am not sure if it needs to be done during an Interlock or not.

Crazy eh!
Eddie
Workarounds
None
Attachment
N
Comments

None

Server Response from: ETNACODE01