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
<mich...@freepascal.org> wrote:
Can you share your changes ?
No problem. See attachments.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
