[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 10:57 AM, Vinzent Höfler
<JeLlyFish.software at gmx.net> wrote:

> If you access it inside the execute method, you more or
> less crash (or at least leak memory).

You obviously had a problem with access ThreadID before it was assigned.
Accessing it should not arrive at a RAV.  I'm not sure this is on topic...

> It took me a couple of days to find the reason for our application
> crashing and I believe that was fixed quite a while ago. (Somewhere
> around 2.0.4, IIRC). Jonas may remember.

> Excerpt from the workaround I had written then:

>      //-- Overwritten to ensure it starts in suspended state,  woken up
>      //-- by @link(AfterConstruction) a little moment later.
>      constructor Create;

Exactly.  It was poor implementation.  You should have had a global
barrier onExecute.  That would unlock the thread after everything you
needed was readable.  See my project attached a few emails back.  It
demonstrates how things should be done with threads.  Now - fpc
carries one private barrier per thread instance.

Developers of FPC should not always blame the development platform.
They are sometimes going to need to redirect an issue back onto the
developer.  But I do recognize this is a delicate issue.  But slowing
us all down for issues such as these...

Perhaps a wiki article on how to get threads to wait during execute
would have an easier fix.  And I'm sure a 100 people too would have
problems.

But I make a case, that slowing down the entire platform for those who
need help getting threads to synchronize makes for a poor movement
collectively.  Perhaps a plethora of examples could help.


> A similar workaround got into FPC a while later and it *was* for a
> good reason: Safety.

Anyone can make safety an issue.  IMO, cThreads has a lot of RFI.
(Room for improvement).

>> There is no need to block the thread from execution.
>
> Actually there currently is. Otherwise you ask for trouble.

I disagree.  Completely.  But that's just because I'm not tied to any
one way of thinking.

>> 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.
>
> What do you want to tie into there?

I reviewed the pthreads code.  BTW: pthreads is what FPC uses to
implement threading.  The barrier may be accessible therby eliminating
the need for an additional instance being created inside TThread.