Subj : Re: threads do not get cpa
To   : comp.programming.threads,comp.sys.sgi.misc
From : Joe Seigh
Date : Mon Aug 08 2005 11:24 am

Jedrzej Dudkiewicz wrote:
>>>>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% :)
> 
> 
No.  Usually when measuring scalability, it's nice to have a 4 way, 8 way,
16 way system to test on.  On a signle processor, scheduler artifacts tend
to get in the way and obscure your measurements.  The starvation problem
is due to SCHED_OTHER where the locks and wait sets don't have FIFO
service order or some other mechanism which will guarantee forward progress.
It's a scalability problem but its effect isn't so much in overall performance
as it may affect just some of the threads.  If the affected threads are all
of the writer threads you will probably notice it.  If the affected threads
are just some of the reader threads you may not notice it right away depending
on what the reader threads are doing, e.g. if forward progress can be made
as long as some of the reader threads run.

-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.