Re: [patch] fixed both processes in D state and the /proc/ oopses [Re: [patch] Fixed the race that w
Richard Gooch (rgooch@atnf.csiro.au)
Sat, 30 Jan 1999 08:25:19 +1100
[Cc list trimmed drastically: most people probably don't care]
MOLNAR Ingo writes:
>
> On Fri, 29 Jan 1999, Andrea Arcangeli wrote:
>
> > Another way to tell the same: "how can I be sure that I am doing an
> > atomic_inc(&mm->count) on a mm->count that was just > 0, and more
> > important on an mm that is still allocated? "
>
> you are misunderstanding how atomic_inc_and_test() works. The processor
> guarantees this. This is the crux of SMP atomic operations. How otherwise
> could we reliably build read-write spinlocks.
>
> yes, there is no atomic_inc_and_test() yet. (it's a bit tricky to
> implement but pretty much analogous to read-write locks, we probably need
> to shift values down by one to get the 'just increased from -1 to 0' event
> via the zero flag, and get the 'just decreased from 0 to -1' event via the
> sign flag.) Also note that this is all fiction yet because we _are_
> holding the kernel lock for these situations in 2.2.
What about this construct:
/* Only one reader allowed at any one time */
atomic_inc (&read_count);
if (atomic_read (&read_count) > 1)
{
atomic_dec (&read_count);
return -EBUSY;
}
/* Do work */
atomic_dec (&read_count);
return 0;
If you need blocking operation, replace the return -EBUSY with a
schedule() loop. The only race should be that the resource is
available, then two CPUs enter this region and "lock" it and they both
have to retry. But that doesn't really matter.
Regards,
Richard....
-
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/