lkml.org 
[lkml]   [1999]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] killed tqueue_lock spinlock
On Tue, 2 Feb 1999, Patrik Rak wrote:

> > like to play with the lock with sure atomic operations in task_queue()
> > while run_task_queue() is spinning on the lock. And theorically some
>
> Why? On which architecture is not assignment atomic? And that

I am paranoid enough I know...

The C compiler is allowed to do generate code like this in the asm of
queue_task():

bh->next = 123;
bh->next = old_list;

if it will do that you'll see the wrong pointer in run_task_queue().

> assignment does not have to be atomic anyway, as nobody else can set the
> next pointer until it is set properly and used (it's protected by the sync
> bit0).

The pointer is seen by the run_task_queue() loop.

> Well, user access error handling already uses such special pointers...

Ah, I wasn't aware of that... Could you tell me where is it?

> And, anyway, data maybe, but *code* ? It's not ZX Spectrum (cf popular IM2
> setting) :)

;)

Andrea Arcangeli

PS. It's a not so obvious improvement to me though ;)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.118 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site