Messages in this thread | | | Date | Sat, 20 Nov 2004 17:26:40 +0100 (MET) | From | Jan Engelhardt <> | Subject | Re: wait_event_interruptible() seems non-atomic |
| |
>Hi Jan, > >>I would like to also lock Buffer_lock around BufRP != BufWP, but don't see a >>way on how to accomplish this.
>This is not a problem: You compare BufRP and BufWP twice: once within >wait_event_interruptible (without locking) and again a second test in >your uif_read function with locking. >You are right that the test within wait_event_interruptible is >optimistic: a concurrent uif_read could read the new data before the >initial uif_read has a chance to acquire the BufferLock. But it doesn't >matter: AFAICS the test is optimistic, it can't happen that BufRP and WP >are actually different and wait_event sleeps. And the external loop >within uif_read() just loops if the race that you describe happened.
Yay, I see now. It takes a fair amount of looking behind the scene to get the idea. (It's just copy-and-paste from an O'reilly book with a few modifications.) Yes, there is always only one way from any insn you look at, which does not require a lock.
>Btw, could you post a link to the complete driver when asking questions?
http://ttyrpld.sf.net/ -- "kernel-2.6/rpldev.c" in the tarball.
>For example the use of down_interruptible() looks wrong to me, I'd use >plain down().
I'd like to be able to hit Ctrl+C (in the userspace application) whenever possible. If that's not a reason, blame the book http://www.xml.com/ldd/chapter/book/ch03.html#t8 ("the read method" a further down below)
BTW, the complete book is at http://www.xml.com/ldd/chapter/book/index.html
Thanks, Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |