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

[Jonas Maebe]

On 15 Oct 2010, at 15:54, Andrew Brunner wrote:

> rtl changes alone added 20-30% speed increase over the test case.

And in the process they break all tthread suspending under Unix.  
CurrentTM.SuspendThread() will always fail there (it calls through to  
CSuspentThread):

   function  CSuspendThread (threadHandle : TThreadID) : dword;
     begin
     {  pthread_kill(SIGSTOP) cannot be used, because posix-compliant
        implementations then freeze the entire process instead of only
        the target thread. Suspending a particular thread is not
        supported by posix nor by most *nix implementations, presumably
        because of concerns mentioned in E.4 at
        http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#E and in
        http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
     }
//      result := pthread_kill(threadHandle,SIGSTOP);
       result:=dword(-1);
     end;

You replaced a bunch of semaphore create/lock/unlock/destroy  
operations with calls to a function that does not do anything.

> My reasoning for removing the barrier was because that it's purpose
> was not warranted.  Users who create threads know to set values of
> variables before calling the inherited create method to their own
> creation.  If I'm on a massively scaled machine I know how to do get
> threads to execute properly and wait w/o taking up CPU time.  I don't
> want the development platform slowing things down for the few that
> don't understand how to create a thread.

>
> Code snippet from actual source to pThreads...
> void __pthread_restart_new(pthread_descr th)
> {
>  /* The barrier is proabably not needed, in which case it still  
> documents
>     our assumptions. The intent is to commit previous writes to shared
>     memory so the woken thread will have a consistent view.   
> Complementary
>     read barriers are present to the suspend functions. */
>  WRITE_MEMORY_BARRIER();
>  kill(th->p_pid, __pthread_sig_restart);
> }
>
> By their own documentation they admit their own barrier is not  
> needed.  LOL.


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.

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".


Jonas