[fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64

[Andrew Brunner]

On Fri, Oct 15, 2010 at 9:24 AM, Michael Van Canneyt
<michael at freepascal.org> wrote:
>
> Thank you,
>
> I'll study it to see if/how we can do something to increase speed of
> creating threads
> in FPC.
>
> But if I understand you correctly, the WRITE_MEMORY_BARRIER() call is
> beyond our reach, so there's little we can do about that.
>
> Michael.
>

Thanks for all your help too!  I'm just wanting a really stable
program executable.  My goal is to make sure FPC is stable and fast as
possible under Linux.  So any "tire kicking" I do is for the benefit
of FPC - nothing else.

It was also suggested that PThread's Suspend and Resume may not do
anything.  What I would do (if that is the case), is try to find where
PThread has access to the Semaphore  or CriticalSection it has on that
thread... If you could tie into that system, you would be able to not
have that extra inefficiency of the FPC Semaphore (and any the creator
of TThread may have).  All these barriers add serious inline time.

IMO. You must assume that all variables of the TThread descendant have
already been assigned and are valid.  There is no need to block the
thread from execution.  That is unless they are asking to have it
suspended on creation.  And if that is the case... We need to tie into
PThread's Semaphore or Event or CriticalSection and exploit that.
It's going to lead to a really significant gain for TThread.Create.