> it doesn't. the scenario in my first email has exactly one > sleep and one wakeup.
alright. i do see it now, and this does look like a source of many gnarly, and hard to find bugs. pardon me for being so thick. why doesn't wakeup take a function and a pointer analogous to sleep? that would seem to lead one in proper usage. or is there a more subtle hole that i also don't see in doing it that way? perhaps it's silly to put a thumb in the dyke, but it might be better than relying on proper fixes for everything appearing overnight. in the case of this particular bug, i have at least 40µs grace and the change has held up for 12 hrs, where i could crash the machine in <5s before. > as i said originally, it's simply not 1:1. > if you need 1:1, you need a semaphore. unfortunately, we don't have those in the kernel. > p.s. not relevant to your "only one sleep and one wakeup" > constraint, but that last scenario also means that if you > are doing repeated sleep + wakeup on a single r, that pending > wakeup call left over on cpu2 might not happen until cpu1 has > gone back to sleep (a second time). that is, the first wakeup > can wake the second sleep, intending to wake the first sleep. > so in general you have to handle the case where sleep > wakes up for no good reason. it doesn't happen all the time, > but it does happen. this is probablly a bug lurking in many things. - erik
