> > 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/