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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
