Subj : Re: threads do not get cpa
To   : comp.programming.threads,comp.sys.sgi.misc
From : Jedrzej Dudkiewicz
Date : Mon Aug 08 2005 04:49 pm

> >>in a routine you are calling.  Also if you were running Linux I'd
> >>suspect Linux's brain damaged signaling
> >
> > Why are they brain damaged? Where can I read about it? Just asking.
> >
> pthread_cond_signal|broadcast preempts the calling thread.  That can
> slow things down considerably.  For example, a simple producer/consumer
> file copy gets slowed down by 2x or 3x or so.

Are there many more things like this in Linux scheduler?

I've seen this in one of your posts:

 On a single processor Linux system, it hard to get as dramatic numbers due
to the amount of scheduler artifacts that exist when trying this kind of
stuff
on a single processor Linux system. [...] and the
mutex and rwlock versions hang with writer starvation.

Is this related? 99% that yes, but only 99% :)

> There was a kernel patch
> floating around to "fix" this.  Or you could use fastcv from
> http://sourceforge.net/projects/atomic-ptr-plus/
> which is what I used.  Or you could use a sem_trywait/sem_wait and
> do a sched_yield if you had to wait using sem_wait.

I've already seen it. Now I spend my evenings with gcc manual in one hand
(in one window), Intel documentation in second one and try to understand
every piece of it.

> In practice this means that doing the pthread_cond_signal after releasing
> the mutex, instead of while holding the mutex, has some performance
> benefits on Linux since the signaled thread will attempt to get the mutex
> before the signaler has a chance to release it if it is holding the lock
while
> signaling.   Both forms of signaling are correct but the former seems to
> upset some Posix purists for some reason.

Stored in long time memory.

Thanks for an answer.

JD

.