Hello Sven, On Sun, 08 Nov 2009 10:57:16 -0800, Sven-Thorsten Dietrich wrote: > On 11/07/2009 12:01 PM, Jean Delvare wrote: > > > > One thing I do not understand: if yield() is a bug to RT kernels, then > > we would have to remove them all? But so far, yield() still exists in > > the kernel tree, and it serves a purpose. Are you going to ask all > > developers to remove all occurrences of yield() in their code? Doesn't > > sound terribly realistic. > > The flaw in using yield() with RT priorities, is that it doesn't do what > you expect. You know, I did not really expect anything in the first place, given how little I know about RT ;) > The scheduler will run, and pick the highest-priority thread, which is > the one yield()-ing. Unless there are several real-time threads running, I presume? > So the risk is, that whatever the yield() intended to do, it won't do, > and worse, that you will end up endlessly yielding to yourself, locking > the machine. > > So the call is for something more explicit of an implementation. This seem to imply an affirmative answer to my initial question: your plan is to get rid of the ~500 occurrences of yield() throughout the kernel tree? As far as I can see, yield() doesn't have clear semantics attached. It's more of a utility function everyone could use as they see fit. In that respect, I understand your concerns about the coders' expectations and how they could be dismissed by RT. OTOH, I don't think that asking all developers to get rid of yield() because it _may not be_ RT-compliant will lead you anywhere. In the 3 occurrences I've looked at, yield() is used as a way to busy-wait in a multitask-friendly way. What other use cases do you expect? I've never seen yield() used as a way to avoid deadlocks, which seems to be what you fear. I guess it could statistically be used that way, but obviously I wouldn't recommend it. Anything else? I would recommend that you audit the various use cases of yield(), and then offer replacements for the cases which are RT-unfriendly, leaving the rest alone and possibly clarifying the intended use of yield() to avoid future problems. In the i2c-algo-bit case, which started this thread, I can't really see what "something more explicit of an implementation" would be. yield() is as optimum as you can get, only delaying the processing if other tasks want to run. A sleep or a delay would delay the processing unconditionally, for an arbitrary amount of time, with no good reason. Removing yield() would increase the latency. This particular feature of i2c-algo-bit isn't necessarily terribly useful, but the code does the right thing, regardless of RT, so I just can't see any reason to change it. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
