GNU bug report logs - #7489
[coreutils] over aggressive threads in sort

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: DJ Lucas <dj <at> linuxfromscratch.org>
Cc: Chen Guo <chen.guo.0625 <at> gmail.com>, coreutils <at> gnu.org, 7489 <at> debbugs.gnu.org
Subject: bug#7489: [coreutils] over aggressive threads in sort
Date: Mon, 29 Nov 2010 11:16:24 -0800

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:

http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00209.html

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.