Messages in this thread | | | Date | Thu, 2 Sep 2010 22:42:23 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [PATCH] PM: Prevent waiting forever on asynchronous resume after abort |
| |
On Thu, 2 Sep 2010, Colin Cross wrote:
> > Well, in fact that was used in one version of the patchset that introduced > > asynchronous suspend-resume, but it was rejected by Linus, because it was > > based on non-standard synchronization. The Linus' argument, that I agreed > > with, was that standard snychronization constructs, such as locks or > > completions, were guaranteed to work accross different architectures and thus > > were simply _safer_ to use than open-coded synchronization that you seem to be > > preferring. > If I'm reading the right thread, that was using rwlocks, not > conditions.
No, the thread talked about rwsems, not rwlocks. And that's not what Linus didn't like -- indeed, using rwsems was his idea. He didn't like non-standard open-coded synchronization.
> wait_on_condition looks just as cross-architecture as > completions, and is almost as simple.
Do you mean wait_event? It doesn't include the synchronization that completions have.
> I look at it like this: Are you waiting for something to complete, or > are you waiting for something to be in a specific state? Completion > works great if you know that you will only want to wait after it > starts. That's not true for an aborted suspend - you may call > dpm_wait on a device that has never started resuming, because it never > suspended. You can use a completion, and make sure it's state is > right for all the corner cases, but at the end of the day that's not > what you mean. What you mean is "wait on the device to be resumed", > and that's a condition, not a simple completion event. > > > Completions simply allowed us to get the desired behavior with the least > > effort and that's why we used them. > I'm happy with the end result, but I may submit a patch that converts > the completions to conditions for discussion.
Be sure to add memory barriers at the appropriate places. That's what Linus was complaining about in the earlier approach.
Alan Stern
-- 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/
| |