[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, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
> You replaced a bunch of semaphore create/lock/unlock/destroy operations with
> calls to a function that does not do anything.

I did not.  I REMOVED create/destroy/lock/unlock.  I ADDED calls to
the ThreadManager's own functions for thread Resume and Suspend.  Did
you try executing the suspend command?  What happened?

> That barrier has nothing to do with "set values of variables before calling
> the inherited create method to their own creation" (although it's not
> entirely clear to me you mean by that). If you set values that the child
> thread will read after that thread has already been created, this memory
> barrier will not help either. That barrier is again about memory write
> ordering, which could cause the newly started thread to not see all writes
> performed by the parent thread *before* creating the child thread.

Other than waiting for the values to be committed, I just don't see it's value.

> And the reason that's it's probably not required, is because there's so much
> code in between that it's unlikely that any of those writes would still be
> outstanding at that point. It's not "for the few that don't understand how
> to create a thread".

Exactly.  The other code being what?