lkml.org 
[lkml]   [2010]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: atomic RAM ?
From
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.


\
 
 \ /
  Last update: 2010-04-08 14:17    [W:1.432 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site