Messages in this thread | | | Date | Tue, 2 Feb 1999 22:30:13 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [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/
| |