On Mon, 7 Jun 2010 20:05:56 -0700 Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote: Hi, > > If you read an event that occurred after you blocked the task > freezing, then tasks will never get frozen again (until more events > occur). I think my original description was less confusing, but it > seems you got completely distracted by my use of block and unblock > suspend when referring to the user space api. Here is how I understood Alan's approach: Userspace manager (UM) does: <...continuation of function A> 5) unblock from reading a wakeup from wakeupevents-fd 6) thaw userspace 7) return </function A> [userspace sees there is an event; blocks suspend at UM; processes event; consume wakeupevent at UM; unblock suspend at UM;] Unblocking the last suspend-blocker at the UM starts function A: <function A> 1) non-blocking read of wakeup-events-fd (refills wakeupevents) 2) if all wakeupevents are consumed: 3a) freeze userspace else 3b) /* wait for userspace to unblock suspend again... this should take care of the races? */ return; 4) blocking read of wakeupevents-fd <...for continuation see above> You mitigate the race by freezing and unfreezing userspace. If there occur wakeups between 3a) and 4) you will have frozen userspace in vain. So I think the feasibility of this solution depends on the performance of freezing/thawing userspace. I can't judge that. Also I _think_ this is racefree as long as you have the UM properly serialized. Or did I overlook something? Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
