Date: Thu, 08 Apr 2010 05:14:53 -0700 (PDT)
Message-Id: <20100408.051453.231567150.davem@davemloft.net>
To: mschnell@lumino.de
Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org,
       nios2-dev@sopc.et.ntust.edu.tw
Subject: Re: atomic RAM ?
From: David Miller <davem@davemloft.net>
In-Reply-To: <4BBDC7D4.6040301@lumino.de>
References: <4BBD86A5.5030109@lumino.de>
	<20100408114542.47b6589a@lxorguk.ukuu.org.uk>
	<4BBDC7D4.6040301@lumino.de>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1130
Lines: 26

From: Michael Schnell <mschnell@lumino.de>
Date: Thu, 08 Apr 2010 14:11:00 +0200

> If one thread locks the "cpu_atomic_instruction_lock" and now the Kernel
> does a task switch and now a second thread tries to lock it as well,
> same would need to do a kernel call to do the waiting.

Using the spinlock array idea also doesn't work in userspace
because any signal handler that tries to do an atomic on the
same object will deadlock on the spinlock.

You'll have have to do this entirely in the kernel, and your
FUTEX implementation will have to always make the futex()
system call.

It's the only way to do this and have it work completely.

We have to do something similar on sparc32, and the signal handler
deadlocks are very real, many glibc testcases that use threads
and pthread mutexes will deadlock because of this very issue if
you try to do the spinlock trick in userspace.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/