QualityCentral

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

Comments

None

Developer Tools

Database Tools