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

[Andrew Brunner]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl.zip
Type: application/zip
Size: 6424 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20101015/78cab92c/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ThreadMemTest.zip
Type: application/zip
Size: 9140 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20101015/78cab92c/attachment-0001.zip>