[fpc-devel] Threads and alot of crap

[Daniël Mantione]

Op Tue, 17 Oct 2006, schreef Jonas Maebe:

> 
> On 16 okt 2006, at 22:49, Daniël Mantione wrote:
> 
> > In other works, pthreads results
> > in subpar performance,
> 
> Is the overhead of a few user level routines really that big? Once the threads
> are setup, they automatically become kernel threads anyway. Having a user
> level layer in between might even help in some cases (like e.g. if the
> threading subsystem decides that a spinlock is more appropriate in a
> particular situation based on the semaphore's properties).

If I compare my implementation of the Chameneos benchmark with the one 
from Marc (which uses Pthreads directly), mine is about two times slower. 
This is propably caused that our thread functions often require multiple 
Pthread calls, which might result in multiple kernel calls. So it is 
mainly the synchronisation that is the issue.

Of course, if the threads are running independend code with no need for 
accessing shared resources, it all depends on the kernel scheduling and 
there should be no significant overhead. In practise, this is seldom the 
case.

A spinlock is mainly fast in the case the lock is not held, in such case 
no kernel call is necessary. If the lock starts spinning, on uniprocessor 
it won't be released until the kernel schedules the other thread. This 
exactly the idea behind kernel futexes, if the lock is not held, no kernel 
call is done. If the lock is held, a schedule is necessary anyway, so the 
kernel is called. The kernel is in a much better position in this case, 
because it exactly knows which threads it should not schedule.

On SMP it might be the case both threads are scheduled at the same time, 
and here a spinlock might prevent a kernel call altogether. However, 
even here nobody has ever beaten the futex system in performance.

Daniël