[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7489: [coreutils] over aggressive threads in sort

From: Paul Eggert
Subject: bug#7489: [coreutils] over aggressive threads in sort
Date: Mon, 29 Nov 2010 11:16:24 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.0.10

On 11/28/10 23:14, DJ Lucas wrote:

> http://lists.gnu.org/archive/html/coreutils/2010-11/msg00124.html

Ah, sorry, I didn't understand that message and thought Pádraig
had handled it.  On an 8-core RHEL 5.5 x86-64 host I reproduced
the problem with the stated test case:

 (for i in $(seq 12); do read line; echo $i; sleep .1; done
  cat > /dev/null) < fifo &
 (ulimit -t 1; ./sort in > fifo \
  || echo killed via $(env kill -l $(expr $? - 128)))

If I understand this other bug correctly, the problem is that one thread
is using a spin lock to wait for another thread, which in turn is waiting
to write to the pipe.  Surely the simplest fix is to drop spin locks
entirely and use mutexes instead.  Perhaps a better fix would be to
use mutexes at the top level (where threads can write to a file and
therefore can wait) and to use spin locks at lower levels (where
threads are merely storing into memory and thus can't wait).

Chen, do you have any advice on this as well?  I can look into
either fix but am mildly inclined to take the simpler (albeit slower)
approach, at least at first.  Here's that thread again:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]