On Thu, Dec 29, 2005 at 03:34:10PM -0500, Cale Gibbard wrote:
The issue with it taking too long seems to basically be as Joel said, only one of the threads can take that MVar at a time. Even if the time that it's taken is fairly short, if one is running faster than the others, it tries to take the MVar more often, which means that it runs a higher risk of being blocked and slowed down, letting other threads take its place. It essentially just forces the scheduler to be more fair.
I get results that confirm scheduler unfairness. I have numbered the threads and every thread prints it number before starting "read". When there are ORANGE or RED alerts, the output looks odd - below is the result of "sort -n | uniq -c": 53 1 53 2 ... 21 46 21 47 ... 8 109 8 110 3 111 ... 2 998 2 999 2 1000 So thread number 1 managed to run at least 52 or 53 "read"s, but thread number 1000 only 1 or 2 "read"s. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland