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

Previous Next

Full log

View this message in rfc822 format

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

Hi all,

On Mon, Nov 29, 2010 at 11:16 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> 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

I haven't looked at the code in a couple of months, so I wont have a
definite answer
until tonight, but off the top of my head I'm not sure mixing
spinlocks and mutexes
will work, since they exist orthogonally. That is, a thread can lock
the mutex of a
structure, but the spin lock of the structure is still free to be
acquired. The only way
to ensure the struct is locked down is to lock both the mutex and the spinlock,
in which case, what's the point?

The only way this would work is if, when a struct is locked via mutex the only
threads trying to acquire the struct are trying to do so via mutex,
and no threads
are looking to lock via spinlock. I'll take a look when I get home
tonight to see
if this condition always holds.

Previous Next

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