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

[Michael Van Canneyt]

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.

On Fri, 15 Oct 2010, Andrew Brunner wrote:

> rtl changes alone added 20-30% speed increase over the test case.  The
> other changes were made to the actual test case.
>
> 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.
>
>
> On Fri, Oct 15, 2010 at 3:09 AM, Michael Van Canneyt
> <michael at freepascal.org> wrote:
>
>> Can you share your changes ?
>
> No problem.  See attachments.
>